A few weeks ago I launched a new web site for a health care company. HTML, PHP, CSS, and MySQL. No frameworks. No javascript. No garbage.
It replaced a site that was a mess of javascript libraries on top of frameworks on top of a half dozen jquery version and on and on and on.
The company administrators, doctors, practitioners, etc... are so happy with the new no-nonsense site that they raved to the parent company about it. The parent company's IT department looked into the site, asked me some questions about it, and yesterday I was been asked to do the same type of cruft-free rebuild of three other sites that the company owns.
Not buying into the framework-of-the-day hype just landed me job security for the next two years.
> It replaced a site that was pretty much a home-grown PHP framework written by a single developer. Random mixed logic in templates, hard to update CSS and a poorly designed 'not-an-ORM' ORM.
Not to say that your rewrite is like that, but one man's garbage is another man's treasure.
But they won't be able to say it's not maintainable, upgradable, or scalable. And it's documented out the wazoo, all the way down to the CSS both in code and in the accompanying PDFs. The last developer gave zero thought to who would come next. I've given great thought, and included the occasional quotation in the code comments from Goethe where appropriate.
But if the company wants to pay him/her to blow away my work, then that's neither my business, nor my problem.
It depends way more on the organisation or team developing it than on the libraries you use.
Not entirely related, but there is usually the incentive to at least say this for a new person/team coming on because money. Especially for frontends, the new person/team we talk to when going into an existing project, says that it has to be redone because it's 'not up to standards'. That is not because it's not fine and maybe even beautiful; it makes more money to rewrite it. And job security perhaps too. So when someone says something is garbage, I need to assess the reason why; is it garbage or does the person saying it benefit from a rewrite somehow.
When was the last time you had a go at CSS? So much has changed since 2017. You can chuck out the pre-processor junk and just use CSS variables and CSS Grid. Productivity is 10x.
You can even keep it simple so that a page just loads the CSS it needs instead of some 40,000 line ball of junk.
Same with templates, if you are using CSS Grid you don't need the sea of div containers, you can just use actual content elements from HTML5 and never use a div.
Pseudo-selectors mean you don't need spans. You can get pretty things done without the markup in the document. Once you write HTML this way you wonder what on earth people are doing with these impossible toolchain and impossible HTML web pages. Regular development from about five years ago with frameworks and jQuery nonsense just looks like hacks.
It's easy to build a simple website with no frills that does exactly what the client needs -- if you know how to do it. Even then, it is rarely easy to figure out what the client needs!
A colleague wanted to use a Javascript library for something I thought was probably pretty simple. I suggested we take a look at the library and see what it was doing and determine if it was worth the extra dependency. He joked, "If I wanted to know how it worked, I wouldn't have chosen a dependency". Luckily, it's not how my colleague really feels, but this is exactly what's happening most of the time.
Things are over complicated because people don't know how to build them -- they glue together a patchwork of stuff so that they don't have to know. In the end, they tend to build something whose complexity is many orders of magnitude higher than the complexity of the problem they are working on.
Your two years of job security was not for avoiding framework-of-the-day hype: it was for knowing how to do it. It's the simple 30 second, single line sketch that captures the picture perfectly with no extra complexity. That takes years and years of experience to develop -- and a desire to even get there at all.
Point is that SSR (Server-Side Rendering), with a sprinkling of simple JavaScript and XHR calls as required, is enough for almost everything I do, and it means build are really simple. Doubly so with a strongly typed language like C#.
I've worked on Angular and Vue projects, and the complexity level was (subjectively) much higher, despite these particular web apps not requiring any real level of client-side functionality. I find JS tests to be much more complex and brittle than C# ones too. Honestly, I hated it! Now, some of this was undoubtedly because I'm more comfortable with what I know, but certainly not all of it.
I completely agree with all of this. There is probably a billion-dollar market out there for rewriting garbage business apps that were developed using the hipster tech flavor of the week.
Think it will look as maintainable as it is today?
Or do you think a new consultant will roll through and easily sell the client on another rewrite-from-scratch project?
But it could have very easily gone the other way. If your website had complicated validation rules on multi-page forms (not unheard of in healthcare) the site would be better off for some basic state management interacting with a standardized authentication/authorization framework that you didn't have to write.
From what you're describing, it sounds like you did right by the client in this circumstance. But sometimes, it does have to be complicated. And in those circumstances, frameworks and javascript (unlike garbage) have an important place.
jQuery would fit well here.
However I would be concerned about a couple of things if this were me and I was doing anything beyond the absolute most basic web app:
- long term maintenance. Doing something only you understand and only you can maintain (that job security you mention) is a bit of an unprofessional dick move IMO.
- if you need to get other people in to help, you now have to spend more time training then up on your custom system that they don't understand and keep an eye on them to make sure they are doing it right and not introducing security issues
- When your client wants to integrate with some common third party thing ("hey can we put Google maps in here?"/"we need to integrate with stripe payments") you'll need to reinvent the wheel from scratch to do it using your custom system rather than just use a well-supported off the shelf library.
- you'll need to stay 100% up to date on all security issues/approaches/classes of vulnerability to make sure your custom system is secure. Your audit was ok this time, but everytime you make a change to your custom library (e.g. to support Google maps or stripe) you're now going to need to go through the audits again to be sure you've not opened up any new security holes (and perhaps new ones you've not ever heard of because you are only working in this weird little custom system/thiefdom for the past 2 years)
- how to support the INEVITABLE requests for extra features that require something client-side that cannot be easily done with only PHP and static pages. It is not the 90s any more - the cat is out of the bag regarding interactivity ... the requests for client-side nicities that users are used to in other things WILL COME! Clients always want more! :-)
Still anyway I guess you don't need my good luck wishes as I am sure you are correct and that you really have out-thought and out-coded all of the well-supported and well-funded frameworks that have been built by many thousands of people and have been battle-tested in the field for years (e.g. Laravel, .net MVC, struts etc). Because otherwise if you hadn't totally out-smarted the entire industry, I'd be shitting myself and checking my professional liability insurance about now.
A decently structured PHP application is often maintained by nontechnical people with a limited understanding of programming but they can get by with just a text editor and a codebase. I have not come across any nontechnical person who could easily get a react/modern js framework pipeline going to do a small change, not to mention dealing with npm changes. I would almost feel like it would be a jerk move to leave someone without a technical department a pile of react/npm soup right now.
Agreed in general, but there are better free/libre choices. I don't recommend these for greenfield projects.
In most of my personal projects I've been following this approach too, and I must say, I'm so much more productive. I don't find myself constantly switching between browser-, terminal and VS Code-windows. I don't have to do validation twice anymore, and know perfectly where all my data is coming from.
MVC PHP frameworks are very nice and they don't move as fast as those javascript frontend rendering.
Also the ORM deals with any security problems and most framework deals with other security deals too including session handling.
It takes a massive amount of resources to develop your own security, your own data access without any ORM tools, not cause memory leaks, properly disposing of resource.
I'm all about creating reliable applications, but a good framework is a great tool.
I think it's way nicer. I much prefer environments like Sinatra, Express or Flask than full-blown MVC frameworks.
- PHP: A few years ago I heard about how PHP was needlessly complex. I wonder what the recent status of the programming language is. Specifically, do experienced PHP programmers stick to a subset of PHP, as in "PHP: The good parts"? (similar to "Javascript: The good parts"). (side note: As a diehard python person frustrated due to latest versions becoming bloated in features, I fully acknowledge that I'm in the "Python: The good parts" camp right now).
- MySQL is owned by a company lately. I wonder if PostgresQL is clearly a better alternative?
See: https://phptherightway.com
Modern PHP development comes in the form of loading dependencies from Composer/Packagist, rather than offloading a lot of bloat to the language. Lots of things have been deprecated (and even removed, like ext/mcrypt).
Some of the defaults like globals being turned on by default led to security holes. How people were creating sql statements at the time concating strings led to sql injection issues.
There were never any bad parts . There are new features like the spread operator that are newer and not available in earlier versions. I try to stay away from them if I think the application will need to run on older versions but otherwise I feel like I can use any feature.
Postgres needs to run under a specific os user. That alone makes it a poor MySQL replacement
There certainly are some types of apps that are mind-bogglingly complex (e.g. press play and scroll around on https://kepler.gl/demo/nyctrips for one vivid example) but ironically, the real heavy lifting is mostly done with specialized libraries and super-close-to-the-metal code (GSLS), whereas the "modern" stack only powers the "simple" boxy UI glue stuff.
Also, if I were a team lead, I definitely wouldn’t have chosen that stack because it’s harder to recruit career driven developers who don’t want to work on tech that doesn’t help then build their resume.
When it’s time to land the next job, using $cool_kids_stack of the day, you will be at a disadvantage.
For context, when it comes to modern front end development, I’m barely above “not eat the chalk” level of competence so this is definitely not meant as a technical critique.
Any reason they liked it in particular? Faster? Better/cleaner UI?
Their old sites were weighed down with an incredible amount of confusing technology.
I redid the whole thing with PHP/HTML/CSS/JS/MySQL as well, and it's incredibly easy for them to update and work with now. Super simple admin interface, attractive front-end, and the top brass at the company has taken notice.
This is my problem at the moment. I have a nice static site, but I'm facing demands from the marketing team to use Wordpress so that they can make copy changes to the site without having to go through a developer (or learn any HTML).
The funniest comment I have read on this website.
Wait, PHP is not garbage?
I used to code in ASP and PHP back in the day, and that approach made a lot of sense. You'd have things that run on the server, and then those things throw out a website for the user to interact. If there's a need for reactivity, use some JS, but basically it all goes back to the same server program. I always found that this approach was good enough. You could do a lot, heck, I even wrote a browser game back in the day. Most importantly, it was simple, and it led to great web pages that would always work and could be used as such. No JS, no cookies? No issue, your code would just deal with it. A button was a button, and link was a link, and your browser did the rest. Text got sent as html, pictures were loaded or not depending on your preferences. Everything got faster and faster. This was years ago.
In the meantime, I stopped doing web dev.
Suddenly, in the last ten years or so, I noticed that websites became bad. The whole web just seemed to regress. Everything was JS, everything became single page, and if you didn't enable every single function in your browser, or if you pressed the "back" button, or reloaded the page - basically if you did not pretend that the website's UI was an actual native program - then everything breaks. News sites stopped loading text or images halfway through, buttons stopped working. Links were not clickable. Pictures would not show up. LOADING bars and circle-things appeared on websites that were already downloaded on my computer. Registration forms did not load default options, choice elements were empty. Once the page was loaded, everything was sloooooow. Scrolling became "different" and often laggy. Websites would load, then do something in the background to reload into garbled messes. Printing didn't work correctly. It's like Flash websites of my day (that everyone know were terrible and had very few good use cases) became the norm, but without Flash.
What happened to the internet? Why is everything garbage? Did all web developers die out?
I went back to make a simple website for myself. Reading tutorials, it was clear I had to use some framework. It was recommended to use JS, install some sort of server application and database, then a framework on top of that, and then something that runs in the user's browser. But everything was its own programming language, with no common denominator. You'd either need a PhD in JS and server development, or be happy to buy in to some framework that was usually not even very good. I did not understand anymore how web development works. I did no longer understand how the websites came to my customer, what the server did, how and when it did it... and everything was hard, even though this should all be really simple. And what came out was just... bad.
I went back to using simple web dev tools if I need to, and thought "well my needs are just not so advanced". But given that most websites have become so terrible, I just can't help but feel it all went wrong. Whoever thought up this frameworks and JS revolution was probably really smart, and there are probably some really good websites out there.
But I hate the internet now, and I don't understand web development anymore. I'm not even that old.
I'm really glad to see that this no nonsense approach catches on.
I've seen comments like this on HN and then I've seen these types of applications in the wild. I call it the most dishonest form of consulting you can do. You've put a real shine on some inflexible shit and the clients obviously have no way of knowing what they've bought into.
>It replaced a site that was a mess of javascript libraries on top of frameworks on top of a half dozen jquery version and on and on and on.
These people are incapable of correctly evaluating work they contract out, or who is doing it. Why do you think you're an exception in this case?
If I'm the next developer I would thank him.
Ever deal with 5 versions of jQuery that are conflicting. Trust me life is easier in vanilla php.
Popular frameworks are not silver bullets, but apparently it's popular on HN to think so.
Also I'm 97% sure I could own your site in under a day, based on how home-baked you just said it is, and I'm garbage at pen testing.
Healthcare site, you say? Jesus Christ, I hope they have data breach insurance.
Thats from someone who does that for a living.
Modern web-devs move faster than they think, leaving so many doors open. Someone who works on the same system plenty of years had time to patch the doors.
The internal and external security audits already performed by the billion-dollar healthcare company in question disagree with you.
If it's simple enough and they understand PHP well, it could easily be better.
Accessibility Cross browser polyfills Easy translation support Automatic mobile view Developer mindshare
The lack of polyfills is VERY concerning. Your site probably doesn't work on 10% of browsers. And getting from 90-99% is an excercise in futility.
If you used a popular UI framework and transpilation you could easily write a super modern site that works on practically everything back to IE6. And with Vue or React the whole thing could be a few hundred KB, probably smaller than some of your images.
If I was brought in to work on your site, I would immediately rewrite it if it's more than a few pages. Plain HTML with PHP becomes an unmaintainable rats nest if you try to do anything complicated.
First of all, "job security" means that you're irreplaceable, and in the case of you actually being the architect/designer, that probably means you did a (perhaps intentionally) bad job to make yourself the linchpin. Not good.
Secondly, regardless of the first point, programming is hard. Anyone that says otherwise should be avoided like the plague. It's beyond the scope of one individual to be able to keep up to date to all the security issues and gotchas prevalent in a language or ecosystem. This is why you use frameworks. They're democratic units that within themselves handle patches and development in ways that are often better than one "irreplaceable" developer on a unique object (of course, bad developers can still use frameworks and derail the product completely to the point where all benefits of the framework are negated, but that's beside the point).
Someone else mentioned SPAs. I 100% guarantee that no user in the world ever wished for their “back” button not to work as they expected.
Calling themselves “full stack engineers” is another symptom of this.
I'm playing contrarian here a bit, so excuse the unqualified language. It seems these days anyone who isn't a webdev in some capacity* is probably a dinosaur, inflexible, less well-paid, lacks understanding of complex distributed systems, and in any case is irrelevant in the modern conversations around development. Might makes right, after all, there are vastly more webdevs than non-webdevs and the most valuable software companies make their money from distributed systems interfaced with via web browsers... The notable exception is probably the group of native mobile application developers, but that's only become more and more webdev-like since both the iPhone and Android took over, rather than the reverse.
* Even being back-end only for a back-end whose only front-end is web-based. Yeah I am conflating webdev beyond the post's qualified "front-end developer". But the back-end webdev guys get up to the same overly complicated architecture-astronaut crap we like to complain about the front-end webdev guys getting up to. Don't let me go off on J2EE/JavaEE/Spring.
Well, that sure is an arrogant way to present stereotypes as fact. At first, I read this as satire.
You can follow the history of web development and see exactly why the current stack is as it is. It's people building solutions to problems.
For example, nobody thought "I should create a front-end build process to impress my peers!". What happened instead is that repetitive tasks were programmed out of existence.
The web industry is young, you can trace every single steps of it without much research. To claim something as ridiculous as "responded by making the simple things they do monstrously complicated to try to prove something to the C++ guys" is silly at best.
Sure, this may be accurate for some of the junior devs. you worked with in your career. However, this is not representative of the industry as a whole.
I mean, you only need check out all the vulnerabilities in said C++ software for verification of that fact :)
I think what you're trying to say is that you don't consider 'webdevs' to be "real" developers.
Ended up just linking to it directly to the jquery and bootstrap CDN...
It's been a long time since I did any kind of major front end work. I think it will stay that way. I don't do enough work with it long enough to really "get it" and retain it.
Pahahahahahaha. There is no group in our industry with a bigger chip on their collective shoulder than "C++ guys".
Well, a lot of them aren’t - until recently, a lot of front-end developers were actually graphic artists who were more skilled in photoshop than software development (not to knock that skill, it’s a useful one!). It doesn’t help that 23-year-old MBA “unicorn startup” founders have bought into this pipe dream model of software development where a couple of eggheads in the unlit server room develop algorithms that the $10/hour mcweb-developers cut-and-paste into beautiful templates.
This is funny because C++ used to be considered a shining example of this. Software is a flat circle.
This opinion invalidates the rest of your post. If you lack a fundamental understanding what people are building obviously it seems overcomplicated.
It is super common to see "Don't use your back button" messages after placing orders on e-commerce websites.
On the other hand, most frontend developers writing SPAs just use react-router or something like that (instead of reinventing the wheel) and it just works.
Yet there was a post about how specifically to do that on dev.to because their users couldn't tell their modal was a modal, and the solution they came up with was to hijack the back button.
Some SPAs are cool. Easyeda.com is pretty cool.
But also: storing information about a page in the URL is pretty cool too. It makes it possible to link to the page, for instance!
Now I feel like I have little hope. I'm under the foot of 117 leaky abstractions which all have their own opinion as to how things should work. It's near impossible to peek too deeply inside, so I just try shit until it works and then attempt to figure out why.
Some of my happier moments are when I get to add to one of our older sites that use server side generated pages. Even then though... not the same as debugging an errant pixel.
I always think the backend versus front end statements are hilarious when cast to other activites. They always carry a tone of derision while completely missing the point that they are different problem spaces and skill sets.
You can fix race conditions on single threaded JavaScript code now we have async (and promises): it scares me how little this is recognised as a downside and in my experience few people are good at recognising or writing code that avoids race conditions (I have seen competent programmers in denial about the risks).
Before async I found race conditions in popular (and well written) JavaScript code that used setTimeout().
Personally I think anyone that enjoys chasing race conditions is mad: I loath reproducing transient errors. I have mostly tried hard to avoid async code in my own JavaScript, but sometimes it is forced upon me :-(
The outside perception, I am afraid, affects me. I don't want to be stuck all the time doing things that are equally hard, but much less appreciated.
I have a lot of respect for frontend development, and approach it with the same kind of caution and respect that I do the backend stuff, however that is not always appreciated, and since it can get complicated fast, and people are expected to finish quickly as if on a treadmill, those things get messed up, hacked, and brittled up.
Another analysis paralysis issue with frontend is cost/benefit for doing it "right." Since frontend is a leaf and not the dependency of another layer in the application, it becomes dispensible to a certain extend in some scenarios. It is seen as replaceable and not worth spending a lot of time on. So when working on frontend, second guessing whether it will be scrapped off later is always hanging in there, paralysing you between "engineering" mode, or just give it a quick hack.
I would not dread doing frontend development, if allowed to do things correctly.
And while my upstream devs will be happily accepting my patch because it quite obviously visually fixes the problem, you'll still be explaining to your upstream why their "perfect" ad hoc threading abstraction is indeed broken.
I think this would be true if the race condition was in my own code, but doing this against another codebase would be pretty brutal...
Part of the reason Flexbox/DOM is painful is that it's very much "someone else's view/code/logic/etc."
So now we have meme frameworks and transpilers and hysterical build toolchains all for a platform for sharing documents.
No full stack developer feels they aren't a real developer. But I think more than anything the full stack's have been the drive of a lot of this complications because all these complications make everything way easier for us.
Web development today is easy (compared to 15 years ago) once you know this toolchain. And for professionals, tools that take a long time to learn but increase productivity tremendously are much better than tools that are easy to learn but slow to use.
Of course we'll figure out how to simplify this toolchain over time. But things have been improving across the board for professionals.
It is unfortunate that the barrier to entry seems to be raising even higher. But a trade-off we seem to be fine making.
Web development is harder for the simpler tasks that were common 15 years ago. It's harder so the harder (or impossible) tasks of yesterday, today and beyond, are easier for some values of harder and easier related to time and custom coding.
So off they go and try to prove that perception wrong by piling on the complexity.
The problem is this is incredibly valuable and we have no good alternatives. There is simply no better format for deploying applications than the web.
HTML/JavaScript isn't the best way to develop an app, but it's good enough and you can develop very good apps with it.
Yes, because that's valuable to the business. My department makes money doing what we do, I'm making my life easier using an SPA framework.
Browsers are awesome at rendering HTML. They render each element the instant just the necessary bytes have crossed the wire. Browsers can't help you if you need to first load the HTML, then load the scripts, then load the complete giant JSON blob from your API, then add the elements to the DOM.
I'm in Norway, with high ping to the US. My ISP isn't the most reliable all the time. That nice server you have 0.01ms ping to, where you can't notice the difference a few extra roundtrips makes? Well, each roundtrip might take an extra few seconds for me.
God it went downhill lately. It can take 20 seconds on a decent machine for it to load all the shitty plugins i dont even need but still block me from using a mailbox..
Loading "html only" version is pretty much instant and has everything I need to use the demn mailbox..
In fact, I'm pretty sure Github is rendered server side for the first load. You shouldn't be seeing any spinners. I'd check if I wasn't on my phone.
It's not that difficult if you're a decent programmer, and if they're not then why hire them?
It's not just web development that is hard. You can't honestly say any toolchain on the desktop side is any easier.
That said, web development is getting easier now that the dust is settling and only a few major frameworks are used.
Get started with create-react-app. React is the industry standard, use it.
1) Install NodeJS
2) npx create-react-app demo
People bitch about the web being too hard and too many choices. Then when you say to just use the most common stack, they bitch that you should choose X instead. Doesn't make any sense.
React also has the largest ecosystem, is the most flexible, and the most feature complete. (I can natively target nearly all mobile/desktop environments)
Packaging these without depending on preinstalled software is hard (you probably shouldn’t even bother trying on Linux, everyone there expects installing weird stuff to involve using either git or a container anyway.)
As far as I can tell the main reason people don’t use it is that it can’t make iPhone apps.
additionally, if your app has any design/layout issues, now you need to hire for people that can do visual layout using tcl/tk.
If your app consumes rich text, you're in for a real treat as you are now on the hook for figuring out how to manage that as well (in addition to serialization, you also need it to likely be emitted into some web friendly format anyway. if your app consumes some feed (say new-user facing features or whatever), you need to find some meta-format that your app can use to layout that content (or i mean, i guess you can use a webview, but then...)
if your customers are enterprise-ey, you are now dealing with some overzealous IT dept that is skeptical of your application running with user permissions.
if you're trying to push a fix/update to your users, you now need to build infra around deploying new apps as well as customer support determining if users are somehow running old versions when they report a bug.
the web is a total "mo money, mo problems" situation, but i think people dismiss how many problems the web solves for your developers on a day to day basis: easy to push updates, simple to whitelist your app's domain on some restricted network, easy add dynamic content/layout to portions of your app with stored content, (less sync resolution issues because your app probably requires network to operate) etc. Native apps have their own issues, they're great, don't get me wrong, but people demand a lot from basic apps of any stripe these days, and as those requirements increase, so does the amount of complexity that developers need to manage at all stages of the pipeline.
> Because we're no longer making websites, we're making apps
This is exactly right. Some projects should be SPAs, some SSR, some just a little HTML and jQuery. Use the right tools for the job.
Why, yes. Yes, I can. Delphi, for example. Visual Basic. Frankly, I think Cocoa and Gtk+ are easier.
2) npx create-react-app demo
How many steps does it take to start from scratch with other toolchains?
And all these years I thought that HTML was the industry standard...
There was nothing, technologically or organizationally, preventing web development from becoming so complicated, such that websites whose desired functionality would be satisfied by static html are now several meg of thousands of lines of javascript on top of a few dozen included libraries. There was nothing preventing that. Therefore, it happened.
Developers don't really feel like pointing out, "you should get rid of me and just pay for someone to do html". Managers don't really feel like pointing out "the project I'm managing doesn't really deserve a team of developers, you should take them away from me." The designers don't feel like pointing out "all we really need is to put this well-formatted text on a page with the company logo on the top and one or two image files, and that will communicate the information just fine, you can get rid of me." The even-higher-ups don't really feel like pointing out "I don't need to hire all these people, you can take this VC money and return it to the original investors". The VC's don't feel like pointing out, "there's not really a use for this much money in the tech world right now, so you can just stick it in a bank account and wait for a real need."
So, it doesn't happen, because there was nothing to prevent it.
> There was nothing anymore preventing web development from becoming so complicated
The early web was much simpler because of the resource constraints of the 90s and early 2000s. Pages only started serving 10 MB of JS when browsers got to the point where they could chew through 10 MB of JS at a barely acceptable pace.
Also:
> Managers don't really feel like pointing out "the project I'm managing doesn't really deserve a team of developers, you should take them away from me."
As a techie watching corporate politics from the sideline, this was a particularly depressing insight. I used to wonder why big companies require 50 employees to do the work that small companies need 10 employees for. I do not wonder anymore.
I used to think when I first started my company that I could just do every part of it far better than anyone else. I would push on my employees pretty hard and often denigrate their efforts. As the company is continued to grow, I now have 180 full-time employees. The reason I have all these people is that they can do enormously more work than I can and most of them are now better at doing their individual job than I am.
I think your comment visits are tendency as tech people to view ourselves in the best possible light, and to view other people as not as good. We especially tend to view projects we do as big and very complex and project done by others as not impressive.
You do make something of a good point about nothing preventing web development becoming over complicated, except you seem to have forgotten how much that costs. Unless there is a perceived marketable difference, people will rarely push for it to be developed at all, and given the size of the average development team's backlog that pressure to develop also has to outweigh everything in the backlog as well.
The honest truth is that web development has become so complicated because that's the equilibrium point of the supply of labor to the demand for advanced features. Developing the same features from scratch using static web development methods takes exponentially longer as a function of feature complexity, and the ability to use frameworks and other more complicated tools reduces that down to being merely linear.
Web development isn't complicated because nothing is stopping it from being complicated, it's complicated because consumers want features that they assume should be simple, but are in fact very complicated.
Not to mention, saying any of those things would make you a "bad culture fit" and potentially break the "no assholes rule" if you argued the point.
I've been working on the server- and client-side of the web for about 10 years now, and I can't recall running into these "wandering pixel" issues they talk about in the past ~4 years.
Frontend development is not just about building a cute website for grandma anymore, and that's why it's complicated. We're passing more responsibilities to the browser, and we have to care about performance when doing work there, and that's why it's complicated. Writing performant software for an unknown machine is hard, and that's why it's complicated.
I think web frontend development transitioned from "acceptably complicated" to "way too complicated" some time around that time the first person wrote "Front End Developer" on their business card.
Don’t get me wrong — being a skilled developer (in the traditional sense) with significant competence in frontend development is extremely attractive. But this profile is actually quite uncommon imo.
I have to ask, do you really think the problem with frontend development is about performance? That FE is hard because of the code is executed on unknown machines?
This does not resonate with my experience.
FED is now about solving harder, 'more real' problems, and performance is one of those problems. Writing performant code for -potentially- old machines, mobile devices of various kinds and in the end different browsers, requires a different level of expertise. This is why I'm a bit triggered by the 'wandering pixels' and 'cant do css' comments, and I do apologize for getting a bit intense.
Recommended reading:
- "Responsible JavaScript: Part I" by Jeremy Wagner (https://alistapart.com/article/responsible-javascript-part-1...)
- "A JavaScript-Free Frontend" by Matt Reyer (https://dev.to/winduptoy/a-javascript-free-frontend-2d3e)
Disclaimer: I'm from Germany, but have a 6-y/o Android phone and live in a rural area with poor EDGE connectivity (~50kb/s). Most "modern" websites don't load/work for me.
Here's my hot take: JS is good and has made the web better.
Not every site needs to be truly interactive. Not every site needs JS. Unless you're building a 3G+ or desktop-only web experience, use it responsibly.
But does the website you're building need to be interactive? Usually not, unless it's a webapp. (Maybe for form validation but that's pretty much it.)
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
It’s true that you can create a MVVM app feeling with a MVC framework and a little Ajax, but really, I’ve never been more productive than I have with react.
I don’t think it’s really that much more complicated, but I do think 99% of the learning resources are outright terrible, and that was certainly a hurdle I had to overcome. Which is hard, because learning new things while you have a full time job is already hard.
Do you use webpack? Just babel? What about grunt/gulp? How often do these things change? If you left your project for 12 months, would it still work?
It's really not that complicated.
Thus, growing pains and overly complicated frameworks/plugins/other bits slapped together to address the core issues which ballooned the complexity. But we all knew that.
What's more impressive is that things are getting less complicated. Browser monoculture, while bad for the freedom of the web, is going to simplify things radically. Only having to target rolling releases for Firefox and Webkit? That's a dream from a cross-plat support side. Also javascript is actually pretty good now. Webcomponents once Chrome 77 drops and Firefox matches parity will finally be production worthy, and they're actually quite easy to build. I've been making static sites with them recently and it feels so much cleaner than going with a React or other component library approach that uses a vdom. The HTML is readable again, and there isn't any needed compilation step or crazy npm dependencies.
While it will never be as easy as it was back in the mosaic days, web dev is simplifying.
Over what timeframe? While it certainly had its own issues, the HTML5/jQuery pairing easily fit into your head. Notwithstanding the benefits, React, packers, routers, and the 10 other things you bundle, is a cognitive load. Doesn't help that the routers and 10 other things don't come with React, and so, choices vary across teams.
What's changing in Chrome 77? A caniuse search for "web components" does not turn up anything that's not old news.
One of my clients was an airline. He asked if we could track the usage stats of his in-flight entertainment system (just stats, no PII). I thought about it and said yes. Even I was amazed I said because a decade ago it wouldn't be possible. I got it done with service workers (because flight wi-fi isn't a 100% always on connection).
It was a boon for me because I made a lot of money on that project and I needed the money. It's also a curse because every browser has all these invisible code running behind the scenes whether you want it to or not.
I miss those days where everything was just a bunch of tables and default system font-powered webpages with plain blue links. No CSS, no popups, just html and pure content.
As a developer, I can say that it is designers and product owners who push for the needless jazz in many many cases.
You mean like HN? You 're not missing it. The old web never left. It's still here to catch all the misguided cloud walkers when they fall.
If you've ever written or worked on a classical desktop application, you'll know what I mean. Since (at least) the 90s there have been visual UI builders and geometry management tools that allowed you to easily define a responsive user interface and connect widget events with calls to back end code. With the advent of CSS Grid and Flexbox, we finally have two decent geometry management tools--it only took 20 years. Except I can't use them yet, I have to support terrible old browsers (like IE7) that are embedded in customer applications.
We've been involved in reinventing a pretty, zero-config version of X-Windows, and we're only about 60% of the way done. How much further would we be if we didn't insist on building it in a hopped up word-processor?
So now we are using HTML, CSS, jQuery, babel, webpack, webpack dev server, webpack hot reload plugin, webpack plugins to load resources and a minifier. But hey, keep it simple, right?
When he was born I used to dream of having him look at a button on a web page and him asking me "what actually happens when I click that button"
I shudder to think where I would even begin to answer that today.
https://flems.io/#0=N4IgzgpgNhDGAuEAmIBcIB0ALeBbKIANCAGYCWMY...
nb. You don't need to jump in with any of the frameworks used by companies targeting millions of users. The basics are still there...
The generators can also do things in really dumb ways that make it slow or resource intensive and you'll have no clue why your elegant solution is running like a dog unless you go through and read the horrible generated code to see what it is actually doing.
I'm developing a dashboard, nothing fancy but nothing simple. I am also reasonable and think one can build off of all the well established UI components out there such as Vuetify. I now have a lot of free time to spend on the backend API, which is what I happen to enjoy doing.
As a fan of end to end or integration testing, I could care less about test driven development on the front-end.
Setup a web server: * VM from Cloud provider * Installing a bunch of staff * Throwing in a k8s cluster * Service mesh * Yaml files * Various network configuration * DNS * Firewall * Security etc.
hey what's your timezone? no, i don't mean getTimezoneOffset(); https://www.iana.org/time-zones LOL
I get that the flash plugin sucked and was a battery hog.
But the development environment was quite decent. I'd love to be able to make HTML5 content in the same kind of way.
My current favorite is the ClojureScript ecosystem, but it's even more different than either still, and really only suited for apps. For a plain old website composed of several pages, mostly static content, it's hard to beat plain old HTML with maybe a light sprinkle of JS for a couple things.
Nah. Nobody cares. I think that bears repeating...Nobody cares.
My mum has __never__ said to me "I love React" or "Isn't Bootstrap the best." But she __has__ complained to me about a site/app being buggy, confusing, difficult, etc. I've said the same to myself too many times to count. I think we all have.
A couple months ago, I read an article about (frontend) tools and how important X, Y and/or Z are. The author's product had a repo on GH. There were 700+ issues. All I could think was, "Apparently those tools have given his team a false sense of security. Looks like they've bitten over more than they can chew." I filed the article under: Just because you can, doesn't mean you should.
Years ago, I remember reading an answer on Quora (when Quora still mattered) that included:
"A fool with a tool is still a fool."
I don't think I'll even forget that line. It's so true. I'm not against tools. I'm just not in favor of those who claim tool X, Y or Z is a panacea.
In any field you can find people putting blind trust in tooling without knowing how the tool works or what its even intended for.
Or maybe non-JS developers are just upset that they had to wait for Docker to be invented to do it themselves.
"Modern web development" tries to reinvent too many wheels.
I wish more developers/directors would try to approach this from the other direction: Making native OS apps as easily discoverable, installable, accessible, navigable, sharable, restorable, updatable and uninstallable, as websites:
• I want to be able to type "photo editor" and see Pixelmator on macOS, Paint.NET on Windows, Photoshop on both, and GIMP on Linux.
• When I choose an app it should open as fast as a website, loading incrementally, but remain available even after I'm offline (except for internet-dependent features) like other native apps.
• It should always launch the latest version, but should also allow me to "freeze" and locally archive a specific version.
• It should adopt the look, feel, and all the special features of the OS and device I'm currently using.
• I should be able to capture the UI state as a "link" and share it with other people, for example a specific page in the preferences window, or a particular workspace layout.
• It should remember my preferences across machines and OSes.
• After I have stopped using it for a while it should not take up any local storage on my machine.
We already have high-performant, energy-efficient UI toolkits and graphics and audio engines, we already have task switchers and various accessibility features, and we already have everything else that every web app is constantly trying to reinvent, each in its own half-baked way.
It's a constant shuffle of N steps forward, N+m steps back. "Oh look! A cool new technology for native apps! But wait, let's take a very roundabout detour to reimplement this in a crippled imitation so that browsers can host it too."
The insane number of tools and processes was the motivator behind Hackterms (https://www.hackterms.com) - the Urban Dictionary for programming terms, and a sort or modern Jargon File. We're now at ~1200 definitions and I reference it regularly.
Was it the inflow of too many mediocre graduates that needed help preventing themselves from writing buggy programs? The social credits that people added to their CV for making yet another uber-popular javascript thingy that got a lot of github stars? Or was it bored engineers in the major web companies who have nothing to do because their advertising money cow is already being milked, so they decided to build toys to sabotage everyone else?
> Was it the inflow of too many mediocre graduates that needed help preventing themselves from writing buggy programs?
IMHO? Pretty much. That end result is linked to the desire to democratize programming. That was a common talking point back in the 90s-00's. They wanted normal, non-programming people to be able to make websites by themselves without programmers. They wanted to be more inclusive and make programming more accessible to the masses. They thought one day programming would be taught in schools right next to english and they'd use that skill every day to program their computers themselves. The common phrase used was "programming is the new literacy."
They did not succeed. To make the programming tools and languages easier to use, they had to add complicated abstractions. Objects. Exceptions. Garbage Collection. Types had to go. As a result, programming got a lot easier to make simple things, but a whole hell of a lot more complicated to engineer solid, reliable systems.
A lot of the comments in this very comments section show a great deal of fear at not using a framework to program even a simple website. That's a great example of the kind of mindset we've cultivated over the past 30 years. We're so worried about how to utilize an ever growing pool of barely computer literate junior developers that we've Harrison Bergeron'd our best and brightest.
Although lots of cool stuff is possible, I suspect that very often, it's about profiling and tracking users, and not about delivering content. That's certainly my experience as a user. I routinely browse sites that call resources from numerous sites, and want to run multiple scripts. And all they're ostensibly doing is displaying some text and images.
Yes, web development is complicated. Yes, that complexity is at times completely unwarranted. But, that does not mean that the originators of this complexity were simply being stupid. A company like Facebook has a simple requirement: keep users on the site. If that means building a completely overengineered platform or inventing a totally new front end framework, sure, go for it! As long as it keeps the experience so smooth, so seductive that people scroll for hours, absorbing ads and producing money for Facebook.
I wouldn't be surprised if someone did some user testing and the SPA with no jarring refreshes and fluid page changes scored significantly higher on user engagement.
If you look at the companies that have really fancy JS libraries, they're generally places that rely on people using their apps continuously. Netflix? They're practically the poster child for internet addiction. Twitter? Yep. Even old school media companies like the New York Times are starting to use fancy web technologies. Clicks and eyeball time is money. Stuff like React and transpiling and webpack are small prices to pay if they keep your front end developers happy and your website nice and shiny for your average user.
People seem to get openly frustrated if they can't learn overnight all there is to know about a discipline that has taken some people years and maybe even decades to master.
We as a civilization haven't really had a need to reconcile this I think on the scale that we do today. Nothing was "out in the open" so much so as it is today. But now that I can see it somehow my expectation is that I should immediately understand it.
As more and more information becomes available to the masses we all need to start recognizing that just because we can see it doesn't mean we should expect to be able to understand it.
Real knowledge about how to solve complicated problems takes time and discipline to get to the place we want to be individually and collectively.
the web is a mess on the front end for political, rather than computer science, reasons
(say, you don't want to include the 2mb outdated moment.js? well, even though every browser included this code to fetch and update it's IANA timezone database in it's source, and has compiled against it, you can't access it via a public API from JS though LOL... you can figure out a way to run this code to get your data muahahahahahah.... https://www.iana.org/time-zones)
1. https://www.scientificamerican.com/article/fact-or-fiction-n...
We can complain about it all we want but if you drop out of this for a few years, good luck. I know tons of senior dev's who have no idea what modern tools to use. They don't understand modules, loaders, config files.
Trust me on this, the front-end guys like myself, hate the backend guys that come along and criticize everything they know nothing about. They also get in the way as they bumble and stumble over concepts UI guys already know. There is a huge distinction these days with backend and frontend web development. Each should avoid criticizing the other.
The current complexity is a result of addressing these issues and doing so at a rapid pace.
Basically, developers can support complexity <x>. No matter what you do to simplify it, you'll always push toward <x>, just getting more value out in the process. If you don't, your competitors will.
Also, even the most complex rollup/webpack/react/redux/styled-component/npm/blah/blah/blah setup has nothing on the kubernetes/kafka/databases/queues/whatever infrastructures of the world.
It just turns out that while your little pet project that cuts every corners to get something working has little on software development that requires everything to line up, be fast, reliable, comply with all the laws and regulations, and scale once your company grows and you suddenly have hundreds or thousands of people that need to work on the same stuff.
One thing to add: some people actually like setting stuff and optimizing infrastructure, build processes, setup, and pushing it to its limits. So development stacks quickly get optimized for a very common way to staff organizations: have a team that handles all the setup and infra, and a bunch of teams that build on top. So when you try to have 1 person or 1 team do everything, it feels like too much.
More complicated answer: The weak side of the open source world is that it attracts a lot of developers with big egos who think that their fancy solution to a situation without problems is the best one. And they all compete with their too big egos and complicate our open source world.
Real answer: too much memory, this causes people to come up with too complex systems as there is hardly a limit to their dreams, real inspiration comes from dealing with limits. That is why programs from yesteryear are often so good when looking at what they do within their constraints.
So now you can be more expressive, target more browsers easily, have greatly simplified script loading and module management, much, much better debugging tools, with less effort.
The tools make it easier for you to be a good developer.
Good web development was never easy.
I'm too stupid for Electron, though. I wasted many hours trying to debug weird errors which I never know if are caused by Electron itself, bundlers, npm modules not compatible with it or anything else like division between main/renderer process. I just can't grasp it.
I ended up with separate node.js server which takes care of communicating with OS and standard web app with the simplest bundle setup I have found (because I don't understand webpack config, too): Parceljs. Frontend and backend exchange information using socket.io with copy-paste examples from their website.
I couldn't believe it CAN be so simple! Maybe it's not "true" desktop app (it just opens in user browser), but works exactly like I want.
Everything is a trade-off. The usual cause of excessive complexity is engineering based on the latest fad, instead of what is actually the best choice.
To many people, backend and infrastructure work is sexy. They would happily get their hands dirty and spend insane amounts of time debugging mind-boggling issues as long as they happen server-side.
Frontend work on the other hand is not, it seems. Maybe that's because the biggest problem of high quality frontend development is to figure out how to deal with users (who most deveopers seem to abhor), and how to navigate the, say... complicated circumstances that are browsers.
Maybe building something that has to work in an environment you can't control is just a little too stressful for most devs?
Personally I really don't care. I love doing great architectural work, but in the end I'm all about expertise and I don't discriminate. If I have to step-debug inside webpack plugins or understand Safari CORS handling quirks, so be it. I'm a software engineer, but to me sexiness is in relentlessly looking for an edge, happy customers and signed contracts.
JavaScript I was paid to write in 1995 had a shelf life of 6 months given Netscape’s release schedule and I had to compete on performance with Delphi 3 native compiled code.
If you think web development is too complicated these days, you should just dump it all and write cgi scripts in Perl again.
Or if you’re an academic, Smalltalk + Seaside.
If there is a problem with modern web development, it is the curse of too much choice. Focus on your end goal, and the choices available will become a blessing, not a curse.
I recently went to work a two big company, which is considered highly agile and progressive. I was tasked to build a pricing engine to customize prices for a static inventory of products. Number of products were about 30 and did not change month to month. The architecture suggested we use close to 18 different technologies, including caching systems, message bus, reactive programming. All to give 10 possible prices for 30 products. So essentially 300 values and a system to change the rules which determined the prices based on 3/4 parameters. I built the entire system in 2 days which was ready to be tested, but was told to scrap the work as it did not follow the internal development guidelines. Not to mention I was reprimanded for not including team and calling a complex problem trivial as it increased signaling risk internally. Apparently they are still building that system with 5 engineers, 2 analysts, 1 devops person, and 1 team lead. I left the company 2 years ago. And interestingly each and every person on the team got a promotion, multiple performance bonuses in last 2 years.
Also, an application software vendor had A(m,n) problems and thought "What we need is to make the Web into a universal platform capable of supporting any application." Now they, and the world, had A(m+1, n+1) problems.
We as a civilization haven't really had a need to reconcile this I think on the scale that we do today. Nothing was "out in the open" so much so as it is today. But now that I can see it somehow my expectation is that I should immediately understand it.
As more and more information becomes available to the masses we all need to start recognizing that just because we can see it doesn't mean we should expect to be able to understand it.
Real knowledge about how to solve complicated problems takes time and discipline to get to the place we want to be individually and collectively.
Given how much I spent doing things this way, I'm quite reluctant to building JavaScript, let alone CSS (though preprocessing first came to CSS, if my mind serves me right). I find the write-test-update loop to be much tighter for frontend work, so I'm quite fond of the old ways of doing things (and all my side projects look the same way as they did back in the early 2000s), but I understand that modern build tools are getting more and more performant. Not as performant as "Save" though :-)
I still stick with Ruby on Rails stack. It has a bunch of good practices and patterns built up over the years.
On the good side, I set up a static Jekyll site using Github Pages. It comes with SSL from letsencrypt. I got to run my website for free without much setup. I assume I don't have to worry about scaling it either. No server, no nginx, no SSL config. It's amazing!
There is a lot to be said for simple, time-proven technology.
[1]: https://medium.com/@mattholt/its-2019-and-i-still-make-websi...
Ironically some of the tools in the article will probably grow old which is part of the difficulty here. People learn the libraries, then it seems a new, better library comes along and makes things even better. Everything comes together once you learn it's about managing the algorithms, data, as well as rendering to the screen.
But what I feel quite frustrated about, is the pace at which tools become obsolete. It seems that you can be happy if you have two projects which actually use the same set of tools. And every time you want to fix a bug in some project which you didn't touch for a few months, you run into some kind of trouble while updating the dependencies.
Just today, I spent an hour getting a project to build again, which I built two years ago. I just hope that in the near future the community will settle on a common set of tools which will become stable and stay for a decade or so.
For personal projects, React on Rails (+ Redux) has been a very productive setup. Once you get over the learning hump of how to set up a project it's basically the same thing over and over again.
For my current project I needed a GUI that I initially planned to implement in the browser, but then I started to question this assumption that web development is simpler, and decided to try to refresh my C++ and use Qt instead.
So far it's not a disappointment.
I wrote a bit recently about that here, if you are interested and can bear poor English:
In any given technical environment that has sufficient time to mature there will be more information to process, more choices, and more surface area. It's just the principle of intellectual entropy. Stuff tends to get larger and more complicated and specialized because it is.
If you want something simple, why not invent it? There's nothing stopping the next person from coming along and coming up with something that gets the same job done a lot easier than what we have now.
Of course, the first time you try to implement a tiny portion of a browser primitive like drawing a table you'll quickly see why things are complex.
To all the people saying that you want a native-app look, then go for the native way. The web-apps will _NEVER_ be as fast as the native ones, just because, the native ones will be faster and faster as the hardware specs are going up. I personally hate to go through web-development, even if it's a desktop client: stop wrapping around web views.
Also winricklabs.com
It's a nice breather after writing AngularJS for six years... I'm sure with the next complicated UI I'll use some big framework (Spring+Leaflet or Angular...)
However, I think the goal should be to reduce complexity and have your business/product be focused as possible.
Watch.ly is literally just live hit counters. The live part gets challenging at some scale. But the product is focused.
Given the choice between learning the business – requiring lots of talking to users to understand what they do and why they do it, and then writing very plain uninteresting code that servers those business users’ needs – or learning whizzy new CV-enhancing technologies and using them to invent excitingly complicated and interesting software problems so they can spend all their time solving those problem instead, which do you think the indolent bums are going to embrace?
Rise of the SPA is great. However, I think unless there is a good reason for having a SPA such as hybrid mobile app development, then there is no point of using SPA.
Normal server side web page rendering with latest modern version of jQueryish/Zapeto should be just fine for the non app type of web development.
* Javascript has evolved from simple requirements e.g. flashy text to a full blown application environment, but there is relatively little base functionality included (e.g. compared to what you get in Java or C#) so people need to write those libs separately.
* The separate libraries above need to be included in your code, and copy/paste is not maintainable so some kind of module system is needed but JS doesn't come with one, so various people rolled their own and they competed for mindshare. 10 different standards.
* As above for UI frameworks. JS only has a basic framework included: the DOM. It's pretty good but doesn't scale "naked" to more complex apps, so again the community creates a whole bunch of those.
* As above for application frameworks (UX frameworks)? such as routers so that you can press the back button.
* Ah the back button - an example of where apps on the web have to care about something that desktop apps don't. There are other examples. Mixing http/https. Mobile responsive.
* CSS - I imagine originally designed for "documents" - now has to work well with "web apps".
* Javascript again - no static typing, many devs find it too easy to make mistakes, we have Typescript and other compile to JS languages.
* Because of the above complexity with have Babel, Browserify, Webpack etc. (one is never enough!)
* Then some genius decides to use JS for the back end and we have Node, NPM, and then because Node is so useful it becomes the front-end tool chain provider. So you use NPM to install Webpack, and the newbie has to figure out difference between dev dependencies and ordinary ones etc.
* git clone https://github.com/... and who knows what stack they've used. Oh they are using Browserify. Never used that. 2 hours reading the docs.
* Each framework then finds ways to get more complex organically. React, Redux etc. and all that.
* Again every other programmer is using 10^10 different combinations of frameworks and techs. Compare to C# Desktop development where it might be they are using Winforms or WPF - that's your only problem!
I could go on. I still copy and paste my favorite templates for getting started with NPM/Webpack/Typescript. Not sure I could demo how to get there from scratch again. All the recommended ones online seem to have beartraps in them and stuff I don't understand.
But remember you all you need is a <script></script>! It's easy!
- React or Vue?
- Redux or stateful components?
- GraphQL or REST or RPC?
- SSR or SPA?
- ...
We are missing a framework with sensible defaults for all these questions. And that does a good job at explaining what decisions one should take.
I'm trying to build such framework: Reframe (https://github.com/reframejs/reframe).
The software stack is a natural phenomenon that adds to web design's complexity. Ever changing and never complacent, it continues to shape new features that weren't conceivable in the past.
There are other reasons, but that is a huge one.
I found backend development much saner to reason about.
You simply cannot be a monolithic craftsman, who wields only a few tools well. Because if you do that, in 10 years you'll be left in the dust complaining about ageism vs knowing new tooling
I'm not advocating this is a good thing, but its the environment we have fostered for ourselves and now we don't like it.
All the tools that are meant to simplify it.
easy
This is a learning process. It isn't something a tool can magically do for you. If you think you can nail this in two hours or by dicking around with some tool you are lying to yourself. Don't worry, everybody with half a brain will see you for exactly what you are, so be honest with yourself that you probably aren't some software rockstar and learn to take the primitive dumb stuff very seriously.
If you are hoping a tool will magically do it for you then you will continue to suck. The web will continue to be a complicated mystery. You will probably continue to cry about how hard life is and people won't want to be around you.
At the most primitive the web is HTTP and HTML. Don't over think this. If you understand those you have the web. You don't even need URI. URI is an added convenience.
Next, build less shitty HTML. Any HTML no matter how ugly, inaccessible, presentation-oriented, user-agent centered, and otherwise broken is still a good start so long as it displays content to a web browser. The first goal of HTML is something that just works... somewhat. Improve on this. Learn to write better HTML and better content. Most people don't take HTML seriously, but this is really the most important part of building a good web experience.
Third, learn some presentation using CSS. This will take some practice. This takes some real practice. It isn't hard, and you can do really almost anything with CSS. Even still people FEAR the CSS.
Fourth, be a damn programmer and stop being afraid to read code. Learn to write JavaScript. Learn the concept of scope. Learn to really read code. A bunch of tooling and test automation isn't going to read the code for you, though many developers seem to think that is exactly what layers of unnecessary tools are for. Keep this very simple at first. Learn some basic events and then bail out. Don't immediately think you are some kind of architectural wizard, because you will fail. If you think a framework will solve this for you then continue to be mystified and confused.
Fifth, learn the DOM. The DOM is the heartbeat, or assembly language, of the client-side application experience of the web. The DOM is what binds HTML to the browser and CSS/JavaScript to HTML. Without the DOM you have a plain text experience with really bad presentation that you shouldn't be using. Frameworks won't teach you this. The best way to learn the DOM, how it really works, is to learn XML Schema. I strongly suggest this even if you never use XML or schemas ever again.
Build on that. Baby steps. It takes some effort but it isn't complicated.
A back end server with this configuration would have a handler layer for IO, business logic layer and data layer.
DI and IoC ensures that the IO layer doesn't know about the data layer as the logic layer takes it as a dependency. The IO layer consumes the logic layer and the logic layer doesn't care/know about that.
Front end is exactly like this. The data source is REST rather than a database. The UI layer is an event source and consumer. The logic layer notifies its consumers (the UI layer) that there has been a change. The rendering library doesn't matter, it's just a mechanism to represent the events it consumes.
The problem in front end is there has been no rational mechanism for DI in the libraries. React relied on the service locator pattern to deliver dependencies so to ensure quality decoupling you would need to have wrapped your components with a million functions.
``` withTheme(withUsers(withSomethingElse(withAnotherThing(Component)) ```
So rather than that, just use a single "service", redux, and forget about DI. Everything can do anything and all your logic is done inside that one thing.
Angular is no better. While they have a nice DI solution, it still relies on concrete implementations rather than abstractions. So your business logic must live within "angular services" and can not simply be "javascript" consumed by a rendering library.
Vue just missed the point entirely.
React context packaged this problem in an ergonomic box and, in my opinion, is a fantastic solution given the constraints. However at this point, the meta in front end programming is so irrational that it boggles my mind.
In the following example, you can see that I have an application which uses React as a renderer. React consumes a package from /platform. The package has no relationship to the presentational layer.
I could run the units in the package inside node or the browser console and it wouldn't care about its rendering library. The "PostStore" class exposes an API which consists of a getter and a stream. React consumes the stream, because it needs to be notified on changes.
https://stackblitz.com/edit/react-ts-biohay?file=gui%2Fapp.t...
Conversely, this loose coupling means that the view renderer is a small portion of the application. I could swap it out for another renderer. Preact, Svelte, whatever.
Front end is a mess.
If there was a way to quantify a good design vs a bad design through an algorithm then people can iterate in ways that properly and categorically makes things better rather than in ways that are opinionated, vague and possibly even in the wrong direction.
Modern web development is not about making things more efficient or easier to do.
It is about proving you have a job title or knowledge that makes you more hire-able, raise-worthy, title-superior than Junior Devs.
Web dev is actually easy if you want it to be, avoid the hype and use simple tools that work out of the box.
