The answer to "why is ___ so ___?", is very nearly always best when phrased as the question, "what was supposed to stop __ from __?" The answer is nearly always...nothing.
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.
Because it had to play catch up to native apps feature wise due to demand, while building upon a base that wasn't intended for that, while serving the same app to literally thousands of different environments and expecting it to work perfectly.
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.
It doesn't have to be complicated, if you get support from above.
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.
Did you consider that the next developer might well come along and post a similar comment:
> 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.
I am reminded of the Picasso story where he meets a woman in a park and makes a 30 second sketch. The woman asks how much it would cost to buy it and he replies something like $1000 (insert large amount of money for 30 seconds of work). She asks him why so much money for 30 seconds of work and he replies that it took him 30 years to draw that sketch.
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.
I take a similar approach for 9/10 of the enterprise web apps I build, but use ASP.NET Core MVC instead of PHP, and I also favour SASS.
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.
Damn, you broke into my top-secret consulting role ;)
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.
I wonder what your brand new greenfield project is going to look like in five years when it's been passed through the hands of a few interns and contractors and survived a couple different ownership shuffles.
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?
Recognizing the right tool for the job landed you job security for the next two years (and you're deserve it!)
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.
For one-dev sized projects (i.e. simple crud type apps) this may well work.
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.
My background is mainly frontend, but I'm well versed in backend as well. I've been actively advocating at my company to stop with this whole separate frontend and backend, and instead just return plain HTML and some basic JavaScript when needed.
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.
I once worked on a team of about 30 people building a website for a university that could have been a team of one dev and one designer and a static site generator.
Questions for PHP, and MySQL folks (not meant in a negative way):
- 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?
I don't think you're being fair. I certanly agree that a lot of things that should be simple are over-engineered simply for the sake of it, but there are a lot of things that are made possible by modern frameworks.
I'm really not trying to plug our thing now, but if you look at this [1], a short tech demo of the platform we're building, there's no way it could have been built without modern frameworks with the amount of people we're building this
Not that I disagree with your approach technically, but if I did that, I would have felt like I wasted my time. No job is secure and you did hardly any Resume Driven Development.
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.
> The company administrators, doctors, practitioners, etc... are so happy with the new no-nonsense site that they raved to the parent company about it.
Any reason they liked it in particular? Faster? Better/cleaner UI?
What tech you use is much less important than the way you use it. If you build great stuff that works well your clients will be happy, and they'll give you more work. It's not complicated.
Very similar thing is happening for me as well, only for a large property management company.
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.
Yeah everyone assumes you have to build out an SPA and then you need a rest or graphql service behind that. It rapidly gets out of hand for the benefit of having a native like experience you wind up serving sites with 1 gig of us framework content per page.
Because, Webpages have become complicated. Suddenly, you have all this interactivity going on, which you didn't have a decade ago. We went from a series of simple hyperlinked inter-connected webpages to all these popups shoving onto our face, useless fake computer bots pretending to be tech-support and finally big co. tracking every single click, every pixel of your mouse movement. The web has come a long way to support all these.
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.
Webdev isn't complicated. Its actually pretty simple. Because its simple, you can use the extra time you saved to solve complicated problems. Which then brings it back up. When the platform makes THOSE problems simple, you just move on to solve other more complicated problems.
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.
Webdevs tend to suffer from an inferiority complex, that they are not considered “real” developers by the rest of the community. So they have responded by making the simple things they do monstrously complicated to try to prove something to the C++ guys, who simply don’t care, until they try to use the dumpster fire that is any modern website, that is. Then it has the opposite of the intended effect!
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.
It's complicated because the bar in terms of user experience went up (or so they say) and now everyone wants a SPA. Because of this you now have a generation of devs that only knows how to build SPA. I'm actually thinking to move some stuff from Django to Gatsby/React setup just because everyone knows React, and a lot of our new devs don't know Django/Python.
"Everyone wants a SPA" is such bullshit. GitHub used to just load for a hundred milliseconds and then show me everything I needed; now it loads for a hundred milliseconds and shows me a spinner while it does another roundtrip for some javascript, then parses and executes that giant truckload of code, then does _another_ roundtrip to get the JSON or whatever describing the data I actually want to see, then executes its boatload of javascript to update the DOM. Reddit is the exact same story; in the time it used to take to show the content, it now manages to load a spinner. Facebook also just spends the first few hundred milliseconds loading loading indicators. YouTube too.
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.
I think we’ve done a great job of convincing each other within our tech bubble than everyone wants a SPA. Not sure the general public cares for our enthusiasm though.
SPAs don't need to be complicated, people have been developing native GUIs for decades. The source of the problem is the browser event and rendering loop which remains a mystery.
Yes, exactly. But to me in many ways that's application programming on the Web vs. Web programming. It may seem pedantic but it's two separate skill sets, and my teams that do each are separate (I have front-end devs that are basically application programmers using Angular/React and front-end devs who are CSS/JavaScript/Animation specialists -- they aren't the same teams).
This comment makes me realize, I need to get back to my RoR roots and build a server side rendered site again to see what I've forgotten with building React sites for a while.
I'm not blaming the tools, but too often, at least (for me) based on multiple interactions with various devs/engineers - yes, sometimes on Twitter :) - tools are proudly spoken of as a proxy for quality product. That is, I'm using the latest wiz-bam shiny new object tool so the users of the product must be overjoyed.
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.
Web development sucks precisely because we use a document markup language, a document styling language, and an interaction scripting language to build applications. It was bad enough when we just used this mess to make user interfaces.
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?
These "i hate debugging wandering pixels" and "i don't want to figure out why my css doesn't work" opinions sounds like they come from people who aren't really front end developers; like they come from the kind of dev who would sit and complain about the frontend devs on their company, thinking that they're a lower class of people.
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.
> they come from people who aren't really front end developers
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.
The right tool for the job... and a web browser is NOT the right tool to build applications, especially heavy ones. (I suspect it's mostly about a power move from Google to wrestle the control over general computing from Microsoft...)
I believe I am one of the devs that complain a lot about frontend devs, generally speaking...
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?
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.
Simple answer: Because the stupid hipsters try to change a simple concept of a state machine into MVC hell.
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.
I don't know, but I do know I would rather fix a race condition on a multithreaded application than figure out how flexbox works or even understand all the different parts of the DOM.
Web development is complicated because it is no longer web development. It's application development. And nontrivial applications are, by definition, complicated.
I would argue that web development is less complicated than it used to be for the same quality of output. We now have source maps, debuggers, bundlers, more powerful languages, apis and a narrow range of browsers to hit with all that.
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.
As other comments here have said, in different ways:
"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."
Sounds like it would be easier to enrich the browser with native-look controls than create another cross-platform ecosystem. (Let alone that none of the platform owners want to share developoers with the other platforms / they have incentive to lock them in)
In my free time I try to create some desktop apps. It's my free time, so I decided not to spend time learning Qt or other older solutions for desktop apps and go with the Electron.
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.
So... let me get this straight. You are making a website. You do need to load some changing data into it, so just a static site will not cut it. But we want to keep things simple. All we really need are a few AJAX calls and some DOM updates. And just like the author mentioned we don't want to write old clunky JS, we want to write beautiful ES6 code. So we install babel for ES6. And we install jQuery to do our AJAX and DOM stuff. Turns out that if we want to make AJAX calls to our API server, we cannot just load the file in the browser, it expects a server. We look briefly at installing nginx or apache and it seems like a lot of trouble. But we do discover webpack dev server. That's perfect. So we install webpack and configure the dev server. Since we are doing it, we might as well make it run babel for us. And while at it, we might as well do the bundling. Especially, since we would like to use a couple of other NPM modules. Nothing major, just convenience things. And since we are using the dev server anyway, we add hot-reload support. And a minifier, so we can have a minified production build.
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?
Client-side JavaScript is sometimes a good idea, but it's absurd to think that all sites require it, and I think it's grossly overused. Most sites are mostly-static content. If your site is static, HTML and CSS are all you should be using. If it's mostly static, server-side implementations or minor JavaScript sprinklings on HTML and CSS are often simpler, cheaper, and much more maintainable. Server-side implementations tend to be much easier to use, and work just as well when your users disable JavaScript because they want more security and privacy. Accessibility is possible with client-side JavaScript, but it's far cheaper & easier without it. Some sites can't be implemented server-side (or are sensible to do completely disconnected), and then you really do need the interactivity of full-on client-side JavaScript. In my experience, requiring full-on client-side JavaScript tends to be more complex and time-consuming to implement, and often tends to have serious loading time lag (with careful design it can be addressed, but often it never seems to get addressed).
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.
[+] [-] rossdavidh|6 years ago|reply
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.
[+] [-] jjcm|6 years ago|reply
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.
[+] [-] reaperducer|6 years ago|reply
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.
[+] [-] orf|6 years ago|reply
> 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.
[+] [-] mikekchar|6 years ago|reply
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.
[+] [-] GordonS|6 years ago|reply
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.
[+] [-] bob1029|6 years ago|reply
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.
[+] [-] debaserab2|6 years ago|reply
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?
[+] [-] Townley|6 years ago|reply
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.
[+] [-] mattlondon|6 years ago|reply
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.
[+] [-] mixmastamyk|6 years ago|reply
Agreed in general, but there are better free/libre choices. I don't recommend these for greenfield projects.
[+] [-] woutr_be|6 years ago|reply
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.
[+] [-] eddieh|6 years ago|reply
[+] [-] anthony_doan|6 years ago|reply
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.
[+] [-] fizixer|6 years ago|reply
- 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?
[+] [-] mstipetic|6 years ago|reply
[1] https://www.youtube.com/watch?v=SkjMUY_cAmw
[+] [-] scarface74|6 years ago|reply
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.
[+] [-] theandrewbailey|6 years ago|reply
Any reason they liked it in particular? Faster? Better/cleaner UI?
[+] [-] onion2k|6 years ago|reply
[+] [-] dpcan|6 years ago|reply
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.
[+] [-] thewarpaint|6 years ago|reply
[+] [-] shams93|6 years ago|reply
[+] [-] neya|6 years ago|reply
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.
[+] [-] shados|6 years ago|reply
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.
[+] [-] goatinaboat|6 years ago|reply
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.
[+] [-] tschellenbach|6 years ago|reply
[+] [-] mort96|6 years ago|reply
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.
[+] [-] eswat|6 years ago|reply
[+] [-] lawn|6 years ago|reply
It's not that difficult if you're a decent programmer, and if they're not then why hire them?
[+] [-] itronitron|6 years ago|reply
[+] [-] heyyyouu|6 years ago|reply
[+] [-] travisl12|6 years ago|reply
[+] [-] chiefalchemist|6 years ago|reply
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.
[+] [-] daotoad|6 years ago|reply
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?
[+] [-] vcanales|6 years ago|reply
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.
[+] [-] alkonaut|6 years ago|reply
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.
[+] [-] BlueTemplar|6 years ago|reply
[+] [-] sedeki|6 years ago|reply
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.
[+] [-] mark_and_sweep|6 years ago|reply
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.
[+] [-] Yaa101|6 years ago|reply
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.
[+] [-] skrowl|6 years ago|reply
[+] [-] heyoni|6 years ago|reply
[+] [-] aphextron|6 years ago|reply
[+] [-] hombre_fatal|6 years ago|reply
[+] [-] earnubs|6 years ago|reply
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.
[+] [-] Razengan|6 years ago|reply
"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."
[+] [-] buboard|6 years ago|reply
[+] [-] pkalinowski|6 years ago|reply
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.
[+] [-] MadWombat|6 years ago|reply
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?
[+] [-] dwheeler|6 years ago|reply
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.