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.
> 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.
Resources are allocated to their constraints. You spend as much money as you have, as much time as you have, you hire as many people as you can afford, and so on.
It may be because people don't think on an absolute time scale but rather a relative one; if you make 1 million in revenue and you only have 3 employees, you might feel like you should hire more. What happens if you start making one billion in revenue?
Read Bullshit Jobs by David Graeber if you haven't already.
If profit is currently $800,000/year and adding 1 software developer at $120,000/year salary (+benefits, hidden costs...) can lead to $800,001 profit, the company would do it.
And that's actually rational behavior. It's also a very simple and very materialistic explanation of why humankind evolves, bit by bit. It works the same way even for discovering new medicine or any kind of technology.
In the early 2000s I worked for a company whose IT infrastructure was primarily Microsoft based. Maybe about 10% of the company had Macs, and we typically had to fight to get them. The Windows boxes required a huge amount of IT support per capita, while the Macs pretty much just worked and the Mac users didn't need much help. Not to mention that the Windows boxes were notoriously malware-prone and needed constant patches and the Macs didn't. I wondered for a long time why the company didn't just switch entirely to Macs. After all, most of the corporate apps were web-based and they worked fine on either platform. It took me a while to figure out exactly what you wrote above: The CIO didn't want a small, lean organization. He wanted a huge organization with a huge budget, because that's what looks good to C-level executives. Hence, Windows was the officially-sanctioned desktop solution.
I love your comment, but I think it does miss out on some important concepts.
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.
The other thing is, programmers love re-inventing things. Its the standard programmer mindset of wanting to work on problems that are one or two levels of difficulty over their currently capability. And so, they fuck shit up, because only someone whose been in the weeds, knows the ins, outs and the corner cases, is capable actually doing a good job. (IMHO, $0.02, YMMV etc)
I'm not sure if I fully agree with your point about developers or managers not wanting to suggest they aren't needed. You're argument relies on the idea that most business needs could be sufficiently met by static html doesn't really fit how businesses works. If a business in an industry has additional functionality on their page that gives them an edge beyond just text on a page, then it is needed. Additionally, when extra functionality is needed the whole industry is going to compete on that. Most businesses don't have enough extra funds to support unnecessary or non-competitive functionality development, so while there might be something better they could be doing with their money, it's almost never the case that what's being developed is so over complicated or over architected that it would be a better financial move to build a static page or site than what they're doing because losing that competitive edge often results in the company, division or product line failing to get enough sales to continue.
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.
While this is occasionally true, I believe it is most of the time not true. Many, many features (e.g. endless scrolling) get pushed out to consumers who don't want it. By and large, consumers of websites want text and images. The push to put embedded video, lots of ajaxy updating of content, etc. has happened on countless newspaper, magazine, and other websites where all the consumer wants is the words and the images. Many features, like allowing comments, are actively disliked by the vast majority of users. There are, certainly, a few corners of the web that need more than static html, but >90% of the websites in existence that are _not_ static html, should be, and the consumers would like them better that way.
I don't believe consumers secretly yearn for largely text based pages, and that's part of the reason why web development has become so complicated. The fact is, 'you' may believe that a simple HTML page will suit > '90%' of consumers, but until you can prove that objectively, then you'll find that there's a whole industry dedicated to determining what really does suit consumers better.
And it's a multi billion dollar market now.
This is merely my opinion, so take it for what it's worth, but I think it's a reasonable answer to the question in the thread title. Also, why is there so much confusion over tools? Probably because there is so much confusion about what people do and do not like in a webpage / web application.
There's more art to software development than many practitioners would like to admit.
I'm sure there is some research that validates that endless scrolling increases user engagement. High user engagement leads to high user exposition, something that marketers are attracted to and spend lots of money to put their ads, and there you go, more profit due to this feature
This seems demonstrably untrue. Basic html development is vastly cheaper than “modern JavaScript” which would give any company w an HTML-only strategy a huge advantage. Why aren’t HTML-only companies dominating in every market?
Static literally == not using JavaScript to manipulate the DOM. Once you're stuck using JS for core functionality, you really want a decent programming language.
I think people are complaining about two separate things - actually-static-ish websites like newspapers, shipping 10MB, and web apps like Facebook shipping 10MB. The latter is an unavoidable outcome of shipping Serious Software; the former is mostly driven by ad networks, not development ease.
I think static could have multiple meaning, and the one the original comment meant is ambiguous. There are "static site generators" which technically generate static sites, but could still use JavaScript.
Yeah we re talking about html, not static. Plus, iirc, it is actually most SPAs that are ‘static’, i.e served as plain index.html containing all the Javascript.
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.
"What's more impressive is that things are getting less complicated."
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.
There are many JS libraries that are wonderfully simple. I think the problem is:
- Too much choice; it's insane how much you have to decide before you get started: React or Vue? SSR or SPA? REST, GraphQL, or RPC? PostCSS or Sass? CSS-in-JS? What router? Redux or stateful components? Axios or Fetch API? Client-side rendering/routing or server-side rendering/routing? Webpack, Parcel, Create-react-app, Next.js, or Gastby? And the list goes on... I mean that's just nuts.
- State management is inherently complicated; people don't realize that 90% of the case you don't need interactive / stateful views to build a product. People implement bunch of useless interactive "niceness" that are overkill because React allows them to. If you use React as an HTML template engine then React is actually super simple and super neat.
How awesome would it be to have a framework that has sensible defaults for all these questions. And that educates how to decide certain crucial aspects.
For example:
- Use plain old HTML instead of interactive views if you can.
- Don't start with Redux. Instead, use Redux only after you know exactly why you need Redux.
I'm not sure comparison is correct. If you want routing in jQuery app - you will have some similar concept to routers. Using packers is also not required. And if you want some good automating module splitting in jQuery app - you'll probably pick up some packer as well. So it's more like HTML5/jQuery can be compared to just React without additions.
Most of these things that bring cognitive load have some purpose. It looks from time to time that developers start making tools in the sake of tools, but most of the time there's some sane reasoning behind.
It should be totally obvious if you have written or tried to reason about a jQuery codebase that is larger than, say, one thousand lines of code, especially with multiple event listeners reading from and writing to the same pieces of state.
My philosophy in those days was that the DOM is the data store, with accessors that are only used during queries. Done this way, I'd never experienced the headaches people complain about.
Form registration for webcomponents is coming. Personally when trying to create a component system it's been the number one blocker I've had. Your work arounds were not great - either you'd have to mirror an input in the lightdom (not good if you're using a library that strictly enforces a vdom), or you have to use a forked form component (not good as few people will know to use it and will wonder why the x-input isn't sending its data to the form).
Once form registration is in place you'll be able to create component libraries that should truly work no matter the environment or libraries being used alongside them (as long as you have an up to date browser).
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'm sure it's possible. Someone may come along who is all into DrupalPress and Agilereactboxqueryhack and think it's primitive.
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.
There are pros and cons to this. One con is that the next developer might have to spend considerable time buying into your ecosystem to be productive. A pro is that it is easily maintainable by you since you built it; which is also a con since it's not generally feasible for a single developer to cover all the in's and out's of a web ecosystem. Lets say you pass away tomorrow, and a week from now a major security vulnerability is announced that affects your system. If you had used a mature framework (Such as Laravel) with a auto update system in place, the issue might be patched in 1-2 weeks. Whereas in this hypothetical the company has to hire a developer that now has to ramp up on your software, be familiar with the security vulnerability, know how to patch it, and have some guarantee that your system will behave as expected. This puts the burden on both the employer who might not know how to screen the applicants because it's not their domain, and the developer.
Saying software is clean because it is untangled from a larger code base is misleading for most use cases, but especially so for web development. It is also not fair to treat front end and backend code in the same context as you can easily decouple both without (since you didn't mention if the backend itself is custom built by you or not, but it seems implied)
From my experience, going through a vanilla php app to fix a CVE is a much better experience than praying to the Framework Powers that be to have your patch ready and non-breaking when you need it.
People have been maintaining SW developed by 3rd parties for several decades. Something like 5 or 6, probably. With all the various amount of available documentation you can imagine, and that includes no documentation and really stupid code bases, or even no source code and you have to patch a binary.
So while I recognize it can be obviously cool to e.g. have virtually no code but simply use a well-designed and currently actively-maintained third party project, it is not always possible, and if it's not then implementing (or even just configuring) anything on top of fashionable software can also be done in crappy undocumented ways.
So the key is to actually have detailed and useful documentation, regardless of 3rd party stacks (or they very relative "absence", I mean probably don't develop your own web-server nor your own database nor your own programming language nor your own operating system nor your own web-browser...)
They absolutely can and will say it's all of those things - and for the most part the client will be none the wiser. It's practically the first step in relationship building for most agency pipelines.
And here's the trick to not building shit software: don't build shit software. It's a crude way to put it, but the reality is that you can build bad websites in any framework (including old PHP stuff and new JavaScript hype). You can also build good websites in any framework.
It depends way more on the organisation or team developing it than on the libraries you use.
The trouble is that "don't build shit software" isn't actionable advice on how to avoid building shit software. For someone seeking to be a more skillful web software engineer, there's no information there.
This is fundamentally because our industry is built on opinions, not standards.
You talk to one software engineer, and they'll say, "that's built in PHP, so it sucks; it should have been built with npm, obviously." Then you talk to another and they say, "I can't believe they built that with npm, the package management system is just terrible and the whole mess is bloated and there have been a ton of security issues. They should have used a static generator instead." And on, and on, and on.
Now compare this to a mature industry with real engineers who are able to say things like, "sure, that material might not be the most durable on the market, but unobtainium would have added $35 million to the project cost and ongoing maintenance costs would have gone up by another $5 million / year."
That right there is a comparison that developers can never, ever offer anyone that's writing the checks for a project. Nobody's bothered to do that work. We can't even accurately estimate the cost of a complex project given our choice of tools, let alone talk about costs and ROI with different toolchains for the same projects.
This is absolutely shameful IMO, and the reason why I cringe a little inside whenever I see the words "software engineer".
Likely in that other industry the engineer built 100+ other basically identical items that are two or three orders of magnitude less complex and where all the costs and techniques are pretty well known.
Also, those mature industries routinely overrun by millions of dollars and months or years, event though they are dealing with a fraction of the complexity and the costs and techniques are well known.
Software is the only industry where you are asked to build systems that have never been built before but that are more complex than anything ever built in the history of "mature industries", on top of astronomically complex systems, and estimate it with an accuracy of 5 to 10 days and a few thousand dollars.
What they do to the end user might be different, how the pieces come together, it is always the same, unless one is doing curriculum driven development.
I wish we could get away from the fashion show in this industry. Currently we have a React frontend, which just adds extra complexity for no real benefit. But its fashionable.
React (and other SPAs) may be fashionable, but I generally contend that--when written well or even passably, which obviously requires an asterisk lest the Scotsmen come by but I don't think is a very high bar--if nothing else it requires developers to treat a web application as a client of an API rather than tightly integrating it. It enforces a level of separation of concerns that, IME, tends to encourage loose coupling and better design.
Forget everything about responsiveness or whatever (which I find way more valuable than the tradeoffs one makes)--the lack of tight coupling is the real win of React and similar. I mean, if you'd like you can pretty easily build a server-side React app with NextJS and still get a lot of these benefits while using React purely as a pretty-dang-good templating language.
SPA apps will decouple the backend from the front end, but the front end will always be specific to a backend in the vast majority of cases. I don't see how that is so different from templates being rendered on the server.
Old school server side rendered apps are underrated and its perfectly possible to make something that looks and behaves as well as a SPA app for most things.
I disagree that the frontend will be specific in even a "vast" majority of cases--if only because of the obvious proliferation of mobile. And while I agree that you can often make a good-looking server-side-rendered, templated application, I will contest that you can ever make a server-side-rendered, templated application feel correctly on a mobile device.
Even in the case where you do have a specific frontend, I contend that there's still value in the separation because it very strongly encourages (coupled with tools like, shameless plug, nestjs-data-sec[0]) the writing of very clear viewmodels where thought must be put into what exactly should be exposed over the wire in a way that commingling database objects and template logic doesn't allow.
I think server-side rendered pages are properly rated at this point, not underrated; there are places to use them but they're shrinking as other tooling get better. As an example, even I write React almost exclusively because I write React faster and with fewer errors than any templating language I see in common use except maybe Razor (and Razor implies buying into ASP.NET, which, no). React/TypeScript are hard to get wrong and easy to burn through quickly. And I would call a React page rendered through NextJS a "server-side rendered app"--but I get the feeling you would not. ;)
Off topic this but your phrase "lest the Scotsmen come by" intrigued me. It sounds vaguely idiomatic but I don't know the reference. Any enlightenment available?
90% of apps use databases, but that doesn't mean they are just database frontends. If you zoom in there is always specialized domain logic that is custom to that app. If there isn't it shouldn't have been built.
>Software is the only industry where you are asked to build systems that have never been built before but that are more complex than anything ever built in the history of "mature industries", on top of astronomically complex systems, and estimate it with an accuracy of 5 to 10 days and a few thousand dollars.
You are seriously overestimating complexity and novelty of most software development, while underestimating engineering in other industries. I work currently as software developer and previously in a branch of a civil engineering.
Do you seriously think that other engineering disciplines to not have those small little problems that plague us all the time in software development?
They do, but they can offer their solutions based on data, not just whim.
They do also have codified standards, and guidelines and certification exams.
On the other hand software development is relatively new discipline - other fields had hundred of years to mature.
EDIT: and they are catching up with rapid prototyping - it is getting cheaper and faster.
> Software is the only industry where you are asked to build systems that have never been built before but that are more complex than anything ever built in the history of "mature industries"
I have a feeling that some SpaceX engineers would have something to say about this after one of their rockets lands on a floating barge.
> I have a feeling that some SpaceX engineers would have something to say about this after one of their rockets lands on a floating barge.
That is because you are ignoring/left out the critical last part of the phrase you quoted: "and estimate it with an accuracy of 5 to 10 days and a few thousand dollars."
This is particularly relevant because this is a direct response to the following:
> We can't even accurately estimate the cost of a complex project given our choice of tools, let alone talk about costs and ROI with different toolchains for the same projects.
It's especially hilarious because he is comparing projects done by bootcamp graduates to projects done by highly trained PhDs. Some people just don't have a clue about the massive difference involved in webdev type projects and complex engineering projects.
>>>>Software is the only industry where you are asked to build systems that have never been built before but that are more complex than anything ever built in the history of "mature industries"
There are occasionally novel engineering projects. These will be millions of dollars and years over budget, and then will fail. All their "mature industry standards and procedures and certifications" wont' save them.
It's unwise to extrapolate the US defense industry's procurement problems onto the Russians and Chinese. There's reasonable evidence to suggest the Russian Kinzhal and Zircon hypersonic missiles are already Working As Designed, or fairly close to it.[1][2]
Yeah, I used to hold similar naive views fresh out of school. Reality is, at least 98% of the software out there is just redoing what has been done, copy paste for slightly different purposes, integrating libs in slightly different ways.
But maybe its hard to admit it, lower down your ego and be a bit humble. Yes, software development is a creative work, but so are all other engineering branches. And yes, we have massive issues with code, process and people quality across whole business.
> "sure, that material might not be the most durable on the market, but unobtainium would have added $35 million to the project cost and ongoing maintenance costs would have gone up by another $5 million / year."
> That right there is a comparison that developers can never, ever offer anyone that's writing the checks for a project.
Sure they can. At Google there was an internal cheat sheet of "numbers every engineer should know" which included the cost in dollar terms of trading off engineer time vs. memory vs. CPU vs. network vs. user-perceived latency etc. (Actually there were two of them - the more famous one is the Jeff Dean version that traded off CPU cycles vs. L1-L3 cache misses vs. RAM latency vs. sending data over the network vs. compression vs. disk latency etc, measured in nanoseconds) If you had any moderately complex new system, you'd prototype a few different approaches on a small set of sampled data, do some multiplication to figure out how much it'll actually cost in production, then compare that against the engineer time needed for various optimizations. If you were in a revenue-generating area like Search, somebody (usually at the executive level) would also be calculating how much the project was likely to make or lose for the company and ensuring that's acceptable. Not all that unlike any traditional engineering field.
The thing is that the overhead for this process really only makes sense at Google scale. For the vast majority of new software projects, revenues on success >>> developer time >>> hardware cost. So you just assume that if you can get the job done in a way that satisfies the customer, it'll be wildly profitable, and the primary factor to optimize for is developer time. And if the developer can build it, the hardware costs needed to run it will be negligible, so just buy more hardware.
This is an artifact of the software industry essentially being a gold rush, where it's rapidly eating the rest of the world and replacing non-computerized processes that are millions of times slower. When you have 6 orders of magnitude to play with, you can play fast and loose with estimates, because any acceptable solution at all will make you a lot of money. When software has eaten the rest of the world and new systems are competing with existing computerized systems, then it's worth it to start paying attention to things like efficiency, security, TCO. There's some evidence we're approaching that point, but we're not there yet, and it's still more advisable for an entrepreneur to tackle an old-school non-computerized industry than to try and improve on existing software solutions.
> At Google there was an internal cheat sheet of "numbers every engineer should know" which included the cost in dollar terms of trading off engineer time vs. memory vs. CPU vs. network vs. user-perceived latency etc.
Could someone alert Google's web developer teams (in particular the GMail frontend team) about that cheat sheet? If released products are considered as evidence, it doesn't seem like this cheat sheet is used.
I left 5 years ago, but a friend of mine who stayed said that Google's basically given up on trying to hold the line on latency, and recent projects don't care. Which is kinda a damn shame - when we were Nooglers we fought for bytes - but I get the sense that the institutional knowledge about how much latency affects revenue left when Marissa, Amit, Craig, et al departed and Larry & Sergey moved upstairs to Alphabet. Sundar's background is Google Toolbar, Chrome, and Android, all of which are product areas where latency doesn't matter because it's installed desktop software.
Ugh. You've basically made the case for me doing my next project in c++ 17 instead of using it as an excuse to learn Rust. Im morally opposed to c++....
In C++'s defence, the language itself doesn't mandate any protections here (the famous 'undefined behaviour'), but there's no reason your compiler can't add automatic runtime checking against illegal use of null. GCC supports it with "-fsanitize=null" [0]
It's much more than just null pointer dereferencing. Time and time again, it's been proven that Rust protects even very experienced C++ programmers from bugs they didn't realize they're even making.
This is a good point. Personal assurances count for little. No-one is above writing buggy code. Even C/C++ codebases written by very expert programmers, often have pointer-based bugs, especially if large and complex. Operating systems and drivers, for instance.
As well as having free-form pointers, C/C++ also have many, many dark corners.
What proportion of C++ programmers know that comparison = (c == c++); causes undefined behaviour?
It's awesome that Google did that. This is the first I've heard of it. But:
> The thing is that the overhead for this process really only makes sense at Google scale.
The software industry is far larger than Google. If we want to claim that software is a discipline of engineering, we all need to have access to that kind of reference data, rather than trying to feel our way around in the dark in comment threads about blog posts about somebody's personal experiences.
I won't go so far as to say there's no such thing as software engineering -- a number of people working for companies with large budgets have well earned that title, I'm sure -- but the extent to which the term is traded like currency in our industry is disrespectful to the discipline.
> So you just assume that if you can get the job done in a way that satisfies the customer, it'll be wildly profitable, and the primary factor to optimize for is developer time.
The fetishization of developer time is one of the problems slowing the maturation of our industry. It ignores end-user time, it ignores management time; it often focuses solely on the initial development time of a project and ignores entirely the ongoing maintenance time for a project.
How many codebases are there out there that are gigantic balls of mud? How much developer time has been wasted on trying to maintain or refactor those codebases? How many really dumb security issues have negatively impacted companies or end users? How many comments has tptacek left on one little forum in one musty corner of the internet over the years trying to explain cryptographic and security-related best practices to an infinite legion of under-trained developers?
How many people have lost their lives to software defects? Not even the really tricky CS stuff, I mean the kind of defects that any other engineering discipline uses as case studies in their introductory courses.
Which case study would you choose for our Galloping Gertie?
Certainly software has done an incalculable amount of good in the world, and its impact is far and away net positive.
But while software has been busy "eating the world", it has rarely paused to also consider the cost and damage it has wrought and whether there are practices that could be standardized to reduce those negative effects. So I disagree wholeheartedly that we're not yet at the point that these things are important. Depending on who you ask, computer programming is between 60 and 180 years old. That's well long enough for us to begin asking questions like, "what data do we have to support this approach or that approach?"
There is still plenty of room for experimentation and research. There is still plenty of room for hobbyists and tinkerers. This isn't an exclusive-or thing.
As much as I really do appreciate blog posts like this one, and the discussion they tend to generate, and especially that there's a new one to read every single day (he said, wryly), I can't help but see every one of them as another indicator of the immaturity of our profession.
I’d argue that the multiplicity of different programming languages and programming language paradigms suggests there likely isn't a teleological trajectory towards some single standard for programming.
Part of this is because many systems are evolving, because business needs have human inputs and are not always "logical." At the edges where this human interaction happens, we expand the domain of programming to that of human psychology. There definitely are empirical claims we can make human-computer interfaces, but it begins to get a bit messy.
To be clear, I am personally interested in becoming more rigorous about empirically justifying claims I make about the code I write. But I’m also interested in code because many of the problems it attempts to solve map the very complexity of the real world. In many ways, abstraction is a properly philosophical exercise, and I think it’s impossible to separate a pure engineering discipline from this broader context.
Programming is multi-disciplinary, and I think that’s a strength.
Physical constraints are more restrictive than information constraints. Physical constraints keep physical engineering from fragmenting into thousands of different but similar frameworks because the physical constraints rarely allow more than a few solutions to be competitive as best solutions. In information, the bounds/constraints are something more of a constructed popularity contest who the largest players are (Google, Amazon, Microsoft, Facebook, Apple, etc.) which carries as much or more weight than rigorously empirical comparisons.
I’d argue that the multiplicity of different programming languages and programming language paradigms suggests there likely isn't a teleological trajectory towards some single standard for programming.
We also have a multiplicity of building materials, tools, fabrication processes, etc. What's the standard way to make a steel object? Do you cast, forge, stamp, mill, sinter, roll, weld? I would expect engineering as a discipline to have more solid arguments for choosing which (combination) of those processes to use for a particular task than what is typically thrown around in discussions about choosing a programming language or paradigm.
>The fetishization of developer time is one of the problems slowing the maturation of our industry. It ignores end-user time, it ignores management time; it often focuses solely on the initial development time of a project and ignores entirely the ongoing maintenance time for a project.
The problem is that in many projects, especially small web-dev or simple automation projects, you simply don't know if they're going to be profitable. The margins are huge, since the upfront development cost is almost constant, you might lose $50,000, or you might make $500,000, or anything in-between, but you just don't really know beforehand. So obviously in this situation you want to become at least somewhat profitable as fast as possible, and then think about "doing things right" later. Is this horrible practice? Sure. But it's also the most logical thing to do here, because "doing things right" at the start is simply a huge risk that only pays off if you're successful anyway. And people would rather minimize losses than maximize gains.
On the other hand more traditional engineering tasks tend to require big up-front investments anyway, and "failing is not an option". I mean it really kind of isn't, if you need more money and/or more time you'll get that much more often here because the initial investment was so big already. So doing things right from the start makes complete sense.
1 engineer-hour =
W ms/search of latency
X GB-year of RAM
Y CPU-years of processing time
Z TB-year of hard disk space
etc.
The actual numbers are very confidential, I've forgotten them, and they're probably different from when I was there. Basically, everything is computed in dollar terms and normalized to engineer time. You assume your code will live for a certain lifetime (a year seemed reasonable when I was there), and you know how many queries your service currently gets (that's another number-you-should-know: usage data for the product you're working on). Multiply out the CPU usage increase by number of queries to get total CPU increase (you need this for capacity planning anyway), and you can compare that to the number of engineer-hours spent working on it to get cost effectiveness.
Not that software can't improve on this front, but I'm pretty sure that every engineering profession has its fair share of opinions and disagreements around them. Heck, my dad's a general surgeon and he's constantly debating with other surgeons over things like whether a procedure should be out-patient or which procedure has the best outcomes. They have a better concept of outcomes, which helps them make data-driven decisions, but they also have a higher risk profile which slows down the innovation process.
I agree with most of your premise, but I think you overstate it a bit. Like the GP's point above, it seems like you're describing bad engineers. In the good web dev agencies I've worked at, they work pretty hard to make informed decisions which stay within budget and timeline. It doesn't always happen, but that's not just due to poor practice.
> We can't even accurately estimate the cost of a complex project given our choice of tools, let alone talk about costs and ROI with different toolchains for the same projects.
No industry can, unless it's something that has been done repeatedly before. If you ask a frontend designer specializing in WordPress to make a theme for WordPress and implement it, they can estimate it accurately.
What is thoroughly missing from this debate is the age old project management terms of scope and risks. As soon as you enter unknown land, the risk goes up. And risk means uncertainty and probably expenses. And if the people writing the checks change the scope, the original estimates goes out the window. If you're making a building, it's easier to understand that you cannot just change the scope after the blueprint is made. You have to get an architect to remake it, and everything done and ordered so far may or may not be salvageable. It happens in all industries, but just more so in software development.
I think OP's point, or at least my agreement, is how many often pretend the software industry is like other engineering industries and make such implications in their job titles.
There is still a lot of creative art and the more we stop pretending this isn't the case, the more people will be reasonable. There is still an high degree of technicality in the profession, but that doesn't mean its "engineering" -- you can be technical, not an engineer, and still respectable (heck, look at science in general). It's still a complex skill and makes lots of money for many businesses.
>they do not change so robustly & fast in short peroids of time.
Not really, rapid prototyping - especially due to 3d printing - is a thing now - you can iterate on a model as fast as you can in CS/CE.
Also - a lot of engineering disciplines use simulations - civil engineering, avionics etc - so they too can iterate quickly.
We are absolutely horrible at estimating. I had article somewhere that analyzed plenty of CS/CE projects and found that we are good at estimating median, and if something goes wrong in most complex part - the time to delivery can skyrocket 100x.
I think a more eloquent way is to say fundamentally creating long lasting software structures is more of an art rather than a science, and you can't just tell someone "go practice these 5 things and you'll be the next Picasso" you just have to do it a lot of times, over and over, learning from your mistakes.
There are no shortcuts. You have to build a ton of software, and make a lot of mistakes, and most importantly, learn from them. Then there's the other half of the equation and some people just have the creative mind to imagine the right framework, or tool or library or abstraction or architecture for the problem at hand.
The important thing is: Picasso knew what to study. Over time art had established a canon of things which helped people to get better at classical arts. Only after he studied that canon in depth and for a long time he could then break into new territories and start breaking rules intentionally to develop his own style/school.
Our craft is very bad at providing such a canon. It is even anti-intellectual in parts ("what do you mean you cannot be a master after x weeks? You are a gatekeeper! you suck").
That and we are still not sure what is important and what isn't (i.e. what should be part of the canon). Our medium of study changes all the time. Arts medium of study is reality and reality, for all our advances, doesn't really change.
We absolutely have a canon. You show me someone who has studied Dikjstra, Turing, Hoare, who has taken the time to pour over the Art of Computer Programming and Structures and Interpretations of Computer Programs, and poured over Ivan Sutherland, is familiar with the early days of IBM, Fairchild, Xerox PARC, and hundreds of other classics we consider to be "canon" that I am surely missing (just shooting from the hip here), and you'' be showing me, more likely than not, a damn good programmer. We have a canon, we just don't have the same studios, detail-oriented attention spans we once had, and the technology we have built is partly to blame.
Maybe related, you were once considered an ignorant brut in this country and others if you haven't read a library of literary classics, now we have kids growing up who barely know Shakespeare, or the rich body of the writing of the abolitionists or slave narratives (how many people you think in this country that even know 1/100th of what Henry Louis Gates Jr knows?) Do you think W.E.B Du Bois and Booker T Washington are common names anymore? I remember when everyone had the preamble of the Constitution and the Gettysburg Address burned into their minds, now we can't be expected to remember questions for a simple AWS Certification Exam, it's pathetic.
I think it is worth considering whether you may have the arrow of causality backwards. For tech specifically; your second paragraph is right on point. The folks I know who've got a fundamental grounding in the stuff you listed (and I count myself among them) all seemed to have an understanding of What Makes Systems Good before doing so. In many ways it becomes the naming of parts along with elaboration upon fairly basic ideas.
I do not believe in the idea of a bimodal distribution of software development (not just programming) aptitude, but I sometimes wonder.
(Regardless, I don't call myself an engineer. Engineers get sued if their stuff doesn't work. I'm a software developer, no matter how good and careful I might be.)
The "opinions" part is true, and has implications on whoever is paying for the software and whoever is maintaining it (with their own opinions, of course).
A company/client will often make decisions based on "opinions" too. "We need a website, what should we use to make it?" It's a bit of a blank canvas situation at first where a developer/engineer could come in and say "We should do it X way with Y libraries because <some opinion on why it's the best stack>". Devs could have totally different takes on the same canvas by a matter of opinion.
If I were to ask people "What type of car should I buy?", I would likely get a whole variety of answers from hybrids to SUVs to European and Japanese cars based on who I asked and what their own preferences and tendencies are. I may end up happy or I may end up unhappy depending on which opinion I'm swayed by and how much rigor I put into investigating the different opinions.
Software can be very similar when people providing the "opinions" are caught up in looking to use specific tools over trying to figure out an appropriate solution. When developers/engineers/designers/managers immediate choose tools as a blanket solution over understanding the scope and use-case for context, it's a sign to heavily question the authority of their opinions.
Software is an interesting animal because what PHP and NodeJS have in common is they were created as hobbies, as were a lot of the frameworks and software tech the world relies on. Maybe there is a bit of us software engineers liking the shiny new thing?
There are a lot of dynamics going on. One is programmer's curiosity but then there is a financial incentive to be on the latest tech. If you see React jobs paying more than Angular jobs, it might be a sign to jump ship which has nothing to do with technical merits. Then there is things like Blockchain that excites investors and techies alike, even when it's a useless solution for something.
People sitting in a room deciding the genuine best thing to do is going to be hard with all these dynamics going on.
We can't even accurately estimate the cost of a complex project given our choice of tools
We've been building bridges for thousands of years, and still the relatively simple bridge they built down the road from me took 2.5 years to complete instead of the estimated 9-12 month.
I've seen non-science in Healthcare, and I've spoke out against it. I don't really understand why people are stubborn when there is data, and the data is solid.
If I could wish anything in software engineering- follow the data.
I think that's the point. If you're looking for actionable advice in terms of "hammers are better than screwdrivers" you aren't going to find it. You'll find people purporting to give that advice. Look elsewhere, like "best practices for hammers" or "when to use a hammer instead of a screwdriver" or better yet "best practices for working as a team."
It's not Javascript that makes you write shit software. It's trying to write software that runs correctly on a wide variety of platforms that you don't control.
reaperducer's rewrite was an improvement, not because he replaced Javascript with PHP, but because he moved all the logic to the server, which is a single environment he controls. He could have used Node instead of PHP and achieved the same thing.
It's definitely not about the environment. Yes, there are browser inconsistencies, but for the most part, this is not a major issue today. The problem of js apps is handling asynchronicity, having to fetch data from the server and managing UI state and in the case of an SPA, having to take care of routing, permissions, timeouts, errors etc. When you sum it all up, you end up with a front-end that mostly needs to replicate all logic from the server, apart from running the sql queries.
On the other side, when you render on the server, everything is already there. It's easy to write logic when the data you need is an sql query away and all you need to do is spit out some html. What gets a bit complex is keeping working state between pages and this usually requires handling sessions, cookies etc.
Well, the environment isn't the only factor, but it's the biggest one. You have to take care of routing, permissions, timeouts, errors etc on the server as well. Data being "an sql query away" on the server is similar to being "an AJAX call away" on the client.
If you have a UI, you're going to have to manage UI state somewhere. Even if you have no client-side code, you've marshal that state into strings to send to the client, and then parse it all out again on the server when you get the next request. Remember hidden form fields? Heck, this very site has some pretty interesting history about attempts to solve that problem elegantly. It was a PITA.
Ultimately, none of that has to do with Javascript; it's inherent in a client-server architecture. The one thing that is specific to JS is asynchronicity. If you don't like that, ok, fair enough, but that's a matter of taste. It has advantages as well as disadvantages, and with Promises and async/await, it's actually pretty elegant. It's certainly not the case that asynchronicity makes you write shit code.
Your first paragraph is exactly my point. Because in an SPA, you have to handle it in both places, not only on the server. That makes it twice as hard as an old fashioned server-side mvc page.
> Data being "an sql query away" on the server is similar to being "an AJAX call away" on the client.
This is a bit disingenuous, since sql calls in most back end languages are synchronous. Also an ajax call needs to update the UI to tell the user something is happening. This might mean disabling controls, showing spinners etc.
All of this goes away if you only use server-side rendering since form requests are natively handled by the browser.
> It's certainly not the case that asynchronicity makes you write shit code.
But it expands the number of cases you have to deal in the UI, to show all the loading states, error states etc.
There is some truth to it. The whole ecosystem encourages a lot of things that are bad for developing simple, stable, good performing systems. I don't go anywhere near that world unless I have to for these reasons. You get all the downsides of dynamic language ecosystems, with worse compile times than Rust (webpack etc).
In my opinion, the biggest complicator there is in javascript land is Webpack and similar loaders. They do absolutely everything in the name of optimizing performance in production, things which even the "development mode" don't simplify.
I developed my own custom scaffolding for Vue projects[0], which is a lot simpler and customizable. It even allows you to develop Vue projects without a build step/tool, you save and reload. Yes, there are tools that reload the page when you save, but I don't think they're worth the complexity.
It could be further improved to actually compile/build when you actually want to deploy, I hadn't the time or a strong need for it yet. But when you are developing, things need to be simple, I think you need to know everything that is happening in the browser so you can resolve any bug with much more speed and confidence.
I try to know just enough of the $cool_kids front end stack to pass an interview, but I’m very honest - I don’t like front end development and that’s not my forte. Besides, front end developers are a dime a dozen. Your typical software as a service CRUD company, is looking for mere competence and pays at that rate. I have no interest in competing in a commodity market.
Build software that you would still want to work on five years later. That usually means tests (that aren't so embroiled in the technical details they break with every trivial change, but instead describe the business logic that is important for your application), sensible abstractions, etc. Usually from there you can select some paradigms that make sense for you.
Fundamentally, all of it is a matter of opinion. You have a million options and they are all correct. Don't take a million options at once, practice a lot, understand your problem domain. You won't write something perfect every time but you'll write something a whole lot better than if you were using a million frameworks instead of real thought.
The key to being a competent software developer is really, really simple: Learn the Business. Because if you can’t/won’t/don’t understand the problem domain, how can you expect to solve problems in it?
There may not be actionable advice for someone hiring a software engineer if that person knows nothing about software engineering. However, I would argue that that person is in a bad position no matter what. There is actionable advice for a software engineer here insofar as the general 'shitiness' of software is due to a lack of discipline on the part of the software engineer. Having witnessed inexcusable practices like functions that contain 10000 lines 'don't build shit software' sounds like very much actionable advice to me.
If the tool allows you to shoot yourself in the face without warning, and has a reputation/history of doing it to a lot of other people, then the tooling is indeed the problem.
Most tools out there allow you to shoot yourself in the face. In this case, the guy replaced client-side JavaScript (very notorious for its amazing face shooting abilities) with server-side PHP (also, a very notorious face shooter).
The real metric of quality is does it do what you expected. PHP is a gun that sometimes shoots backwards with no sensible reason where as rust has a gyroscope that can work out when the gun is pointing at your face and requires that you turn off the safety first.
Entire classes of bugs simply don't exist in better languages.
Well, yes. You can write a web application in Haskell and enjoy the beautiful and flexible type system, first order functions, monads and all the other wonderful things. But you shouldn't. Because when you leave, the client will never be able to find someone to maintain the damn thing and chances are they will hire someone else to rewrite it yet again in PHP. And possibly hire someone to make a voodoo doll of you and stick pins up its ass.
There's no guarantee that good approaches in 2019 will still be good approaches in 2029 and beyond. OOP was considered a good approach many years ago, and now in many circles it is derided and bashed.
Unhelpful advice. Typical programmer up his own ass bullshit really. Oh that ways not good. Well what's good? I don't know, just not that. Look at how many clowns criticize jQuery these days as an example of garbage software.
jQuery isn't garbage as per se. It's a great library for directly querying & manipulating the DOM.
Trying to make web applications with it is another story though. The lack of any state management is a nightmare, hence declarative frameworks/libraries such as React/Angular(JS)/Vue/Svelte etc. etc. came along.
What makes the lack of state management a nightmare in the javascript world, but a complete non-issue when doing .NET or Qt apps?
As someone who started with desktop apps and then moved into web dev, I never really understood why Javascript developers wanted a library to help them manage state.
All the state management stuff seems to be tied up in (=synonymous with) attempts to purify JS frameworks and codebases, as in "purely functional". It's... kinda silly and far removed from either the problem at hand, or the strengths of Javascript (such as they are) much of the time.
Meanwhile objects representing various parts of the view, and plenty of models that don't look much like "modern" JS state management, remain the norm elsewhere, and the sky is not falling. I do not know what to make of it. I go along with it when in that sort of company—when in Rome, and all that—but the evangelism can be pretty funny.
Anyway a bunch of the stuff isn't half as special as you'd think reading about it through the usual channels. Redux? A data cache and a so-so local event bus with somewhat awkward semantics and a few really bad terminology choices thrown in. Whee. There's your "state management". Not that it's useless, but you'd swear it's black magic reading all the blog posts about it.
The main benefit of purely functional systems is function composition. The ability to build entire programs through the composition of function primitives. Composition without dependencies.
The problem with javascript is that this concept is entirely lost on react developers. Due to the untyped nature of javascript and it's close linkage with html. HTML is made up of dependent components and this essentially puts dependency injection into javascript leading to JAVA like issues that the functional paradigm was suppose to solve.
> I never really understood why Javascript developers wanted a library to help them manage state
The reason is rooted in how browsers work.
In native software you can "just" render your data structures directly to the screen. In the browser, barring webgl, you can't render your data structures directly to the screen, instead, you're forced to interact with an imperative browser API to individually manage bespoke UI widgets that store their own state internally and can't understand nor access any of the data structures defined for your business logic. The only option left is to manually update the internal state of the browser UI widgets whenever you update the internal state of your application. Manually keeping the two states in snyc is a real pain, highly bug prone, and a maintenance nightmare. The front-end browser frameworks came along as a way to "auto-sync" the business logic state with the browser ui state.
That's the same way you work with literally every other UI framework (except the immediate-mode GUIs popular in gamedev), complete with the built-in event loop that's hidden from you. Web isn't special here, except that no other framework I've seen allows you to modify the UI by programmatically editing the serialized text description of it.
> Again I don't understand this argument. What's difficult about it? People have been doing it with win forms for well over a decade now.
And yet it's recognized as a problem there, too, and one of the more recent solutions is state management libraries inspired by those used in Web apps, e.g., there are fairly direct copies/adaptations of React and Redux for .NET specifically to address this issue.
I think jQuery got a bad rap because so many script kiddies would drop the entire damn framework into a page when they just didn't feel like writing a standard selector to do a mobile menu.
I mean, if all you're doing is showing and hiding a mobile menu, you can do that in a really expanded form in like 5 lines of vanilla JS, and not have your user download 90 KB* of crap.
*And you BETTER be using the minified version for production.
90 KB is probably bad for a marketing page, but it’s nothing for a B2B or internal use app, particularly when the second use is just the “you already have it” HTTP header response.
I don't disagree, but when so many public websites are unloading megabytes of Javascript for simple tasks, it feels like that attitude is the core problem. I'm not opposed to using frameworks when they're needed, I just have a problem with people using them to shorten up already short and very easy code because they can't be bothered to Google for a few minutes.
I'm not being hostile, I apologize if you took it that way. I'm just making a point about how so many dev's claim to have the right answer until you need to rely on them to get something done. Projects turn to a mess mostly due to things one single person cannot control. I don't know a single person, including myself, who've thought that their code didn't look like shit 6 months to a year down the road. I think we always get better and we'll always criticize what we don't know and understand. This includes mountains of other peoples code (garbage or not).
He did just apologize in case that person perceived something hostile when it was not meant to be hostile. He should not have apologized it seems. Damned if you do, damned if you do not.
The problem is, even if you try to contribute negative LOC, every other week your boss/customer/PM sees a new feature in their dreams or hears about a new technology at a conference and demands you put it in there right now.
Every system that I've built so far has started out with a simple, obvious set of rules (both new systems and replacements for old systems). Then the customer/PM/whatever notices just one more edge case. And another. And another. And another. The truth is that reality is frustratingly complicated. Especially if the reality you're mapping contains the internal bureaucracies of large companies.
People don't know what that means though. It is only helpful after explaining to shoot for deeper yet simpler rules for your system along with identifying what can be separated from execution as static data.
Part of that mantra also falls under problem solving in general. Not every solution needs a technology solution. Sometimes fixes can be made in processes or policy in general. Many jump to technology solutions too quickly and I feel this is lazy and often passing responsibility for someone else to fix a situation.
Deleting code is not always better. I know a lot of developers who like to "refactor" code by making everything more terse and they regard that as a win even though the code is now cleverly incomprehensible.
I agree, it depends of the code, and if you need to replace it: by what.
I'm actually more found of when I don't even have to replace it: just delete the damn obsolete shit. Not replace. Delete. Most of the time it for cases where it is just dead. Sometimes it is only quasi-dead (from an incomplete previous modification) and in a few cases deleting it actually fixes some bugs.
Having bad software or a bad website is very often not an existential threat to companies, but having no software or no website is very often an existential threat.
The secret is, you don't have to not write and/or delete everything indiscriminately.
The second thing is: companies do not only try to avoid existential threats; they also attempt to have economical approaches. If anything needs to be maintained, there is the potential, if it is crappy, to make maintenance costly.
It locks you, and future developers, into a paradigm. It might not be a "best" or even "good" way of doing things, but, adopting a framework helps keep everybody writing the same 'shit software'.
Consistency, it turns out, is key. That's because (as others have pointed out) all software is ultimately shit software. If you wrote it, chances are you don't think it's shit, but everyone else does.
Agreed. Doing things in a computer is just organizing the information you have at hand.
That could be files or symbols in files that defined a set of operations a computer should run on symbols in another file/db.
This isn’t magic. But it’s susceptible to social behaviors and those are “growth every quarter, demand, demand!” so we latch onto buzzwords or trends because some VC funded dork thinks their way of laying out a todo app is best. IMO anyway.
Having gone freelancer and flipped the bird to corporate life, I’m way happier and write little code: not having to learn new frameworks makes when to write more generic, re-useable, dependency less, code way more obvious. And I don’t have to worry about a Github repo going inactive.
We’re making it harder with tent pool frameworks due to information overload. When the work is information organization, less is more.
A parallel to all that “more data is just a bigger security liability.” theme that popped up a couple years ago. It’s also a progress liability.
I agree as I build some terrible applications in .Net MVC, which is a decent framework. I think you have to build shit software not to build shit software.
First, professional web app I developed 3 years ago is still being build upon now. Even though it is pure garbage and I hate touching it, because I "made it work". As I gained experience and got burned because I did something a certain way I slowly but surely looked for alternative approaches.
Now 3 years later, I'm building an app with layered architecture, proper separation of concerns, dependency injection. Plus, before I start hammering code away, I think about what is the number 1 priority for a piece of code, am I gonna use it once and forget it? Will I use it all the time? Then, proceed accordingly.
I think about what is the number 1 priority for a piece of code, am I gonna use it once and forget it? Will I use it all the time?
I've gone in the opposite direction in my career.
Overbuilding the initial version of something for a bunch of anticipated (rather than actual use/failure scenarios) is something I now work very hard to avoid.
The key IMHO is really being nimble enough to extract and/or refactor and/or refine as soon as it is needed. Not before, not after.
"Overly robust" code is actually a huge problem sometimes. All that unused code is in there, giving the appearance of being robust, but is not actually battle-tested....
" am I gonna use it once and forget it? "
Always comes back to bite me in the a$$.
Also taking over projects that were built this way always a pain. Now and days I just refuse to do the work if they pushing to cut corners.All in all I say my quality of life and the sense of being proud of work has increased.
Eh, many people think "let me shit it out ASAP for those quick bucks", and then there it is. I would say not giving a damn about quality is identical to your quote, feels a bit more passive, but still.
These are strawmen arguments. No one is arguing that libraries matter more than organizations/teams, and no one is arguing that it's impossible to build good/bad frameworks in any given language/framework/etc. You can (and should!) solve the problems with your teams and your tools. If you pick a tool that solves problems you don't have (probably because it's new and shiny), there are probably hidden costs that you didn't consider and you're probably going to slow your team down. How much that slow down is going to affect your project depends on how significant the slow-down is and how sensitive your project is to developer productivity (the widely used internal tool with the big budget at BIG CORP is probably safe, but the team at the small startup with the shoestring budget and fierce competition is going to feel that friction in a bad way.
What if I told you there is a theory about good module design and if you follow the formal rules of the theory (not design principles mind you there's a huge difference) good and organized designs can emerge from just knowledge of the theory itself?
was just about to comment along these lines! i never understood those eschewing frameworks... in the above example a PHP framework like Laravel is in constant development by lots of people, with security updates and refinements pushed out on a regular basis. even if u are an uber-developer, in what situation is rolling your own ever the right choice? is your project that different from everyone else's?
I remember seeing this one post on HN from some PHP consultancy that had open sourced some kind of PHP web app that was "engineered from the start to be secure".
I took a look at the code on GitHub and it was absolutely horrible. They basically built their own mini-framework, poorly, with mixed concerns and poor, ad-hoc and inconsistent validation everywhere. Terrible.
I left an issue on GitHub with my findings and got into an argument with the author in the HN submission about how it's disingenous to say something is engineered from the ground up to be secure, if you're eschewing all the man hours that have gone into something like Larvel. I think his reasoning boiled down to "Larvel has CVE's so it's not secure".
> This is not engineering a project to be "simply secure", in the sense that it is definitely not simple and probably not secure!
Messy, duplicated code that re-invents the wheel hides security bugs.
Saying "Windows has security issues, so I'm going to write my own operating system for my software" doesn't mean you can't knock it out of the park and make the most secure operating system ever... but I wouldn't exactly bet on that being the case.
Why don't you drive an 18 wheeler to work every day? They are used by millions of professional people every day who's job it is to drive! Why would you be different from all those people that you think you need to use a little car instead?
The answer is obvious in both cases; You don't need it and it would be wasteful. If I don't have a huge database with constant read/write calls, If I don't have to try to manage multiple end users submitting content, if I don't need super async real-time snappy UIs to compete with the latest android app fad or session tracking of tens of thousands of users, why would I need laravel?
If nobody rolled their own specifically for what they needed, we would still be writing ASM/APL/Raw hex.
i'm sorry but i'm really not convinced by this argument. there are many frameworks available in various languages/platforms, some created specifically to be light and fast (in the PHP example above, lumen is a possible choice). my other argument would be- why are you spending so much time on plumbing when you could be concentrating on the parts of your application that make it special?
This analogy sort of falls apart in the details. Rolling your own is more akin to building your own vehicle. You might have all the right parts to have a functioning vehicle but you probably don't have the experience of a team of engineers and designers of a commercial vehicle.
In most cases you can buy a modestly sized vehicle from a manufacturer that still has a team of people ensuring the performance, utility, and safety of the vehicle.
I think the main problem with the current Javascript UI frameworks is that they introduce an 'abstract middleman'that distances developers from what is actually happening in the browser. I expect there are many web developers unfamiliar enough with MVC that they are drawn to the Javascript frameworks even though MVC isn't a particularly difficult concept.
But there are tons of laravel sites, so there is a substantial profit motive to look for vulnerabilities in them.
It's like, outdated Wordpress sites get hacked all the time, but if I just threw together my own shitty blog in PHP and MySQL there's almost no chance it would, as no one (generally) is going to take the time to figure out hacks for just one site (especially for SMB).
> but one man's garbage is another man's treasure.
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.
Logic in the templates... are you describing PHP or React?
To be fair the parent comment isn’t saying everything about his stack is perfectly elegant, but if you can deliver a website that works without stateful client side JS and associated build tooling, then it certainly is simpler, and most of the time simpler is better.
As long as the code isn't abstracted more han 1 or two layers deep, it's commented in places where the control flow isn't that intuitive, and follows best practices for whatever the kids of languages is, it doesn't matter if it's home spun. Just being "home grown" is not synonymous with bad software. At the end of the day, just using frameworks are no guarantee that the code is readable and maintainable. Usually by the time someone is looking at your code to rewrite or update it, what seemed like an awesome choice of framework at the time can end up being a nightmare to parse as documentation has dried up, forums that were the sole source of knowledge are offline, and now your once amazing code is just garbage to the poor coder trying to make sense of the random abstractions of the framework.
I would tend to agree. Not a fan of database abuse / contempt. Turn on the SQL trace in Hibernate and weep. So much code wanking to be “performant”, which just waits for horrible database usage to grind along.
Did you consider that up to a certain point any framework, be it home grown or commonly used, makes things more complicated?
Simple cgi endpoints and static files for any css/js should be our starting point and any web developer should understand them. When the problem becomes bigger and more complex is when we should start looking at frameworks.
Not necessarily. If the new developer rewrites in a modern framework again but the user experience becomes terrible (looking at you modern reddit), then the new developer cannot really say that. As a developer, I understand the hard to update CSS etc but that is far better if the user experience remains great.
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.
Easy if you don't have to have it pixel perfect for them. Just build it out with CSS Grid and the CSS variables, then look at the broken mess on IE and make it work. Who cares if things are not centered on IE11. It is not an HTML5 browser and is only there for legacy support - ActiveX and all that.
Also add a banner at the top telling people they need to use their other browser for the page.
What business are you in where 8% are still on IE11?
COBOL springs to mind. It sounds like you have a profitable niche supporting legacy stuff. Edge came out five years ago and IE11 was depreciated.
You can try the polyfill approach. This is generally not recommended as it wastes bandwidth. But since your customers have bandwidth you could go with polyfills. Or just stay stuck in the past with a niche of writing IE11 compatible stuff. That could be career limiting, IE11 is getting as irrelevant as 8.3 FAT filenames.
Edge is supposedly an option even back to Windows 7, though I don't believe it's a required security update. I haven't used a Windows 7 system in long enough that I'm not sure.
At this point it is reasonable to tell people they NEED to install a more modern (and more security up to date!) web browser, be it Google Chrome, Microsoft Edge, or Mozilla Firefox.
The true judge is the user experience, not the code quality. Modern web sites try to be apps, with tons of whizzy nonsense that breaks on user browsers, to the users' detriment, when they should be simple CRUD sites to manage digital files.
Right, but will they be able to say that the customer was thrilled with their rewrite? Probably not; they're already mostly happy with the simpler site and now they've paid to make things (almost certainly) more complex than they need to be. They probably feel swindled into agreeing to a rewrite of something that was mostly working but The Next Developer told them that adding that new feature would require completely rewriting the front- and backends.
Except for the developer who is statistically going to change jobs every two or three years and all of the openings want someone with “$x years of experience with $framework_of_the_day”
And the hiring manager who can’t find anyone that doesn’t want to pad their resume for the same reason.
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.
People vastly underestimate how complex client side code can get and how much automatic functionality browsers hand you. Whereas a nice web framework has users, permissions, session management, templating, validations and forms all set up for you with battle tested out of the box behaviors.
A frontend framework is great if you are a company that really needs to slim down bandwidth and can hire expensive devs to maintain it. But for a simple no nonsense business application it’ll just slow you down and will gravitate towards being a mess.
I haven't tried it, but have read uo a bit and seen some examples.
TBH, I'm not all that keen, possibly because it reminds me of the bad old days of webforms with code-behind files. Maybe I should try it in anger before I judge it though :)
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.
That's definitely something to consider : i don't want beginners to start coding in old school php with sql statement inside html templates because they read on HN to "not use modern frameworks".
BUT, i don't think this "crude design" trend will ever have the same attractiveness to junior developers no matter how much hype it gets here. Being attracted to "new shiny things" is very intrinsic to human behavior, and tech companies will keep spending ads to sell their new tech to the market.
Secretly leave the Android one React Native since it does a decent job of papering over Android's worst rough spots, despite how often React Native breaks and how LOLWTF its ecosystem and release management is?
The market may be large, but that seems like saying the market for cooks is large. The work required for doing 4 sites is double the work required for doing 2. Unless theres some scaling secret I dont know about.
The idea isn't to capture the entire billion dollar market, but to navigate a market that is large enough to safely feed you and many more for the next decade+, precisely because it isn't scalable (so there won't be any FAANG-or-whatever coming along, eating your lunch)
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?
Framework-dependent projects tend to go stale and become "ew I don't wanna touch that, it's so last year, we should probably replace it with [newer version of framework that's gonna end up being much harder to upgrade than expected / other framework]" surprisingly fast once eyes are off them, in my experience. Without someone competent doing continual upkeep, the next guy/gal's gonna try to sell the re-write anyway. May not succeed, but they'll try. Framework or no.
Plain JS is the same. How often do you search something and find the 2012 way includes copying a 20 line util function and the latest way has it built in to the language.
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.
You missed the multi-page forms part. As soon as you have state of some fields affect how other fields or parts of the page display it becomes complex really quickly. There is an explosion of possible states. If you've ever seen code like this, you know why more modern js frameworks were invented:
Not really, this kind of thinking is exactly what led to the client-side JS framework mess.
Round trips are just fine. Browsers are smart, servers are fast, and HTML compresses well. The site you're reading right now (HN) requires a reload. Stackoverflow requires a reload. Neither are slow to use.
If your page is really that complicated, then I suggest Vue or Preact which are efficient and designed to progressively enhance pages instead of rebuilding everything in JS.
Connectivity is not always available, and errors retrieving it may mean you have to re-enter everything. Being able to "navigate" the site without the dinosaur is a tremendous boon for end users. You wouldn't be able to send anything without a connection, but you could buffer it for an opportune moment.
Sites like HN and Stackoverflow have a vastly different audience than most bread-and-butter sites, and tackle different kind of issues.
Most bread-and-butter sites are just fine as server-side rendered page. Large client-side frameworks reimplementing the browser and server functionality should be rare, when the situation actually calls for it.
If you really need a offline site then a simple service worker is all you need to cache the pages, not a big JS app.
Don't underestimate pjax/turbolinks as a first approach. This way you get to render on the server without refreshing the whole page. For most business websites this is more than enough to keep rendering snappy.
Depends on the app. In some cases it results in a much simpler and easier to maintain environment (ie, Larvel or Symphony will do this better than Angular...)
I know. I use server side rendering all of the time - well at least until I got back to my safe place doing back end work. It was one project for $reasons I had to use a very light framework that I could copy paste the entire library into the page. I couldn’t depend on the device having an internet connection. I could also precompile the templates.
Yeah, I didn't really try to make it realistic. But I've seen very similar code, it would maybe reset inputs, calculate some results, stuff you can't really do with a single css class. T
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.
I think people are assuming he wrote a pile of hot PHP garbage, but it's entirely possible he just wrote it using Symfony or Drupal and well understood PHP libs and just has no 'modern javascript' to do it, which if he did would cover all of your points. If you haven't gone back to current gen PHP in a while there are some quite solid models that are very maintainable, have security updates (via composer) and so on. It's entirely possible that he didn't do a crazy thing but we'll never know.
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.
There's nothing in his post suggesting that the way he developed is harder for someone else to pick it up. MVC Frameworks aren't necessarily easier to use than vanilla PHP. Your answer reminds me of people who don't know how to use vanilla JavaScript and have to add jQuery to the project for things that could be one-liners in vanilla JS.
The whole "what if the customer needs something in the future" is just a piss-poor excuse that bad developers make to prematurely optimize. There's nothing in an MVC framework that makes it easier to add new features.
There is nothing preventing him from using official libraries for Stripe or Google Maps if needed.
There is nothing preventing him from using libraries that can be updated, probably with a single CLI command.
There is nothing suggesting his system is unsafe. Quite the contrary.
He didn't outsmart the entire industry. He just built something that works without relying on your favorite tool. Maybe you should try someday, you might actually learn something.
A simple php endpoint is something any web developer can understand. The more frameworks/libraries/patterns/abstractions you throw in the less likely it is they will understand it. Especially years later when the framework is inevitably out of date, good luck convincing why they need to spend money upgrading a framework every year.
> hey can we put Google maps in here?
Has this changed recently? Last I checked you would just drop a script tag into the page, who needs a library for that? Edit - I checked (https://developers.google.com/maps/documentation/embed/guide), how does a framework make a copy/paste job any simpler?
> "we need to integrate with stripe payments"
I'm not familiar with stripe, but don't you just give it a return url? I don't see how a framework would help at all here.
> 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.
This is harder with a framework, it's one more thing to keep updated. The less libraries the less vulnerabilities.
> Doing something only you understand and only you can maintain
Having worked with both kinds of application, I personally find it much easier to learn my way around and understand a self-contained application than one which is a giant web of moving-target third party dependencies and frameworks, themselves largely undocumented and subject to the framework-hipster "move fast and break your users' things" mentality.
Agreed with PostgreSQL. But I'd go with Laravel rather than Django or Rails. More modern, more features, active development and constant new features are guaranteed for Laravel, in addition to growing community and abundance of learning resources.
Except in a case when we want to build an e-commerce website for client. PHP has so many mature frameworks, like Magento/WooCommerce etc. I look at Python ecosystem. Yeah, we have Oscar and Saleor but they are pale compared to their PHP cousin.
But other than e-commerce, yes, Django or even Rails is my preferred choice.
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 built a SPA and found making the API and linking everything up to be needless overhead. The way I find works best is using rails templates to simply insert a div with all the data needed in the attributes and then having react render everything.
That's what we used to do years ago, just render a script tag with all the data required, and then use JavaScript to link it up in the views. But I feel if that's what you're doing, you might as well use a templating engine, and put all the data where it belongs.
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.
This seems odd to me. I have been working in .Net MVC/Core and while I could write an application that is simply HTML/CSS/C#, I would think it would be insane to do so.
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.
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?
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).
I think the discussion point was php was too easy and that encouraged new developers or less hardcore developers to adopt it.
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 where, and continue to be, large numbers of bad parts. Magic methods that do random things in certain cases, terribly defined interfaces (array_search), ridiculous typing, an impossibly incoherent standard library, etc.
> Postgres needs to run under a specific os user. That alone makes it a poor MySQL replacement
Where did you get that idea? Postgres can run as any user.
In fact, I recently switched my applications to use Postgres even during unit tests (instead of SQLite), i.e. that testing instance runs under my normal login user. That change actually made the CI go faster because compiling the Go SQLite driver takes much much longer (about 30-60 seconds) than spinning up a Postgres from scratch in a temp directory (about 2 seconds) and using that instead.
@fizixer: I don't use MySQL, but I've heard it's not nearly as bad as it once was. I use PostgreSQL for everything from traditional relational data to time series to job queues and am 100% satisfied. Hasn't once let me down. The only caveat is that clustering is still easier to do with MySQL than with Postgres from what I hear, so if you have really really big setups that require that, that should be considered.
> I don't use MySQL, but I've heard it's not nearly as bad as it once was.
MySQL 5.7+ is decent. Where it loses out to PostgreSQL is the lack of plugins/extensions. PostgreSQL is extensible in ways MySQL users can only dream of (e.g. timescaledb, pg_trgm)
Also, the forking of MySQL and MariaDB has resulted in 2 very similar databases that people consider interchangeable - but aren't. There's plenty of "gotchas" if SQL is meant to run on both.
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
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.
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.
The point of using a good framework is that conventions and best practices are enforced. If your building a Rails sits there are a set of conventions everyone follows. When a new developer onboards onto the project they know how to extend the code base.
I have a similar story. I got hired on to replace some PHP web apps, each one written using a different framework. Each one out of date, unpatched, unknown dependencies, no easy way to bring up to date-- tied to specific old PHP versions. A big mess. The IT director was pretty savvy and said he wanted a clean rewrite without frameworks, something I was all too happy to do.
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).
"Modern-looking" these days means shitty JS that tries to be a "WebApp" and breaks basic website conventions like open in a new tab middle click, and uses the same GUI both for small touchscreen and large desktop, so ends up working poorly on both. Why would anyone want that ?
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.
Hopefully, considering just how shitty things have become, this will just be a fad that will quickly die out... especially once devs start to catch up on JS advances of the last 4 years?
This sounds like you wrote something extremely limited. The client will inevitably ask for some modification to it, and if you're not there to do it the next developer is going to curse at you for writing such a brain dead application.
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?
I've seen countless unmaintainable applications written using popular MVC frameworks that required simple modifications, but the next person in line wasn't able to understand what the hell was going on.
Popular frameworks are not silver bullets, but apparently it's popular on HN to think so.
I can assure you "owning" a home-baked software is 10 times harder than anything that is popular.
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.
But am I not right to have red flags fly when someone says they built a home-baked web service for managing health care information? Isn't that nuts, from a security perspective?
No, you're not right. How you render CSS and the page have very little to do with how secure your app is.
SQL escaping, session handling, etc all come easily with standard php libraries. So "I didn't bother with any PHP frameworks" doesn't mean the dev wrote an SQL connector.
I'm sorry if you thought I meant CSS rendering was the source of potential vulnerabilities, but for any website that has, say, users, if you're not using any PHP frameworks or external libraries you might have to implement some crypto of your own to store passwords securely, just for starters. I don't think PHP offers a standard library to do that, does it?
There are a hundred examples that are specific to whatever app this guy built for the Healthcare company, not all of which are covered by the PHP standard library...
I believe him when he says it passed external/internal auditing, however I have a very hard time believing he's not either very very expensive or took a very very long time to get the app to the place he claims it is (the third option is that it does very little, which won't actually end up being a good thing once the client gets over the honeymoon phase of "it's so much prettier!!!").
Further, the expertise I do bring to this conversation is in software development, and I can say assuredly that a one-man development team using no 3rd party libraries is definitely creating a codebase nigh unmaintainable by other people down the line. His bragging about creating job security for 2 years is honestly an understatement; he's got job security for the life of the products he's creating, as he's likely the only person who can do anything more with the website in a time frame that isn't measured in years.
"There is no installation needed to use these functions; they are part of the PHP core."
The functions are common knowledge in the community, and made to be easy to use.
> Further, the expertise I do bring to this conversation is in software development, and I can say assuredly that a one-man development team using no 3rd party libraries is definitely creating a codebase nigh unmaintainable by other people down the line.
They said, "No frameworks." They didn't say no libraries. Some people make a distinction between the two, others don't. You are taking the stance that they mean they mean the same thing. Realize that others don't consider them the same thing.
Further, the expertise I do bring to this conversation is in software development, and I can say assuredly that someone who doesn't know the nuances between libraries and frameworks in the software development world can't make the claim to have expertise in the software development world. =)
I don't think someone nitpicking between the definition of the words "framework" and "library" is engaging in this conversation honestly, and I'm pretty sure that your failure to address the "this is but one of hundreds of examples, not all of which are covered by standard libraries in PHP" comment I made is further justification of that belief.
> I don't think someone nitpicking between the definition of the words "framework" and "library" is engaging in this conversation honestly
I think it is, especially since you are nitpicking on it. I'll explain.
If the original poster is using libraries but not frameworks, and feel there is a distinction (and judging by the post, it's clear they feel that way), then they are using libraries, just not frameworks.
Therefore, when you say this: "a one-man development team using no 3rd party libraries" in the context of the discussion, you are making stuff up. No where does the original post suggest or otherwise say that they aren't using 3rd party libraries (quite the opposite).
For your comment to hold up, you need framework and libraries to be the same. However, by pointing out that often times developers see them as different (generally libraries make up frameworks), I'm making it clear that your conclusion is misinformed.
> I'm pretty sure that your failure to address the "this is but one of hundreds of examples, not all of which are covered by standard libraries in PHP" comment I made is further justification of that belief.
I addressed directly the one example you provided. You didn't provide hundreds. You provided one. I provided the answer out of courtesy, as you asked a direction question. Saying answering your direct question is justification of my dishonesty is insulting and childish.
Further, the fact that you are mistaken on the concept of the common use of library vs framework, I felt that your claim of "hundreds of examples" was hyperbole and ignorance. Maybe you can provide hundreds of examples where PHP and libraries written in PHP cannot solve problems that only fully fledged frameworks can provide? Keep in mind that libraries exist for many different things and since frameworks are made up of libraries, there is almost nothing relevant that a framework can do that libraries can't.
> if you're not using any PHP frameworks or external libraries you might have to implement some crypto of your own to store passwords securely, just for starters. I don't think PHP offers a standard library to do that, does it?
"There are a hundred examples that are specific to whatever app this guy built for the Healthcare company, not all of which are covered by the PHP standard library."
You would need to implement whatever custom code required or use a libruary. You would need to do the same with a framework. No framework offers business health care functionality. Do you think laravel has an ocr skin cancer detector package?
PHP is fast to write. Hearing people from the outside saying its impossible to write a php site that quickly makes me laugh. PHP makes development easy.
"PHP is fast to write. Hearing people from the outside saying its impossible to write a php site that quickly makes me laugh. PHP makes development easy."
Yeah that's odd to me too. I mean, that's pretty much the biggest argument against using PHP (well it was, back in the day). Bad sites written easily by inexperienced programmers.
I can't speak to your specific case, but I've seen a tool "pass" a billion-dollar company's auditing because the scanner they used never got past the login screen and their folks never noticed that fact.
I'm super glad to hear that happened, but please understand where I'm coming from when I said what I did; reinventing the wheel (as I'm sure you had to here) is straight up dangerous.
I agree that there are much better choices, but most frontend apps are done with onion oriented development with thousands of dependencies that constantly get vulnerabilities, and aren't any more maintainable in my experience.
If it's simple enough and they understand PHP well, it could easily be better.
Eh, not using popular frameworks is a recipe for unmaintainable sites. You're missing a lot of features these provide for free.
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.
Honestly I think it's kind of worrying that this opinion is so popular. Aren't you essentially saying that frameworks are in most cases useless, and "job security" is something you should strive after?
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).
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.
> 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.
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.
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.
I might have agreed the inferiority complex existed in the early 2000s, but I don't see it anymore. Rather I think the negative thoughts go the other way, maybe not inferiority from non-webdevs, but jealousy. You can find n00bs who graduated a coding bootcamp and are now making a significantly larger amount of money doing webdev stuff than a bunch of middle aged guys working on legacy native applications who studied the arcane C++ arts and had to get a BS degree to even get an interview.
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.
I'm not sure you understand the amount of embedded software that runs the world -- or at least think about it appropriately.
And the amount of system and infra software that is needed to even let the web exist.
An "application" is not just a cute GUI that a consumer or an office worker can interact with. Nor is the interface the most complicated parts in some systems. I found your projection and generalization as ridiculous as if you said: even the EE needs to master the web technology, and they are not very valuable if they don't.
Hey, they are web devs of various levels. It is ok to be one, especially a good one. It is also ok to be, I don't know, a compiler expert, a kernel hacker, a baseband FW engineer?
The thing is: you often forget about what works pretty much correctly and silently, even when you use it all-day long... :P
I didn't forget about them (my own degree is in CE) and did say I was being somewhat contrarian... And started off impugning on the notion of jealousy (possibly driven by economic value -- I'm not making professional use of my CE degree in part due to $$$) rather than inferiority or even competence in those who stir up the "ugh webdevs am I right?" rhetoric. We probably don't disagree much on the value of people, generally speaking, or the lack of recognition of types of excellence including all the great volunteer work going on in free and open software.
> Webdevs tend to suffer from an inferiority complex
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.
You can follow the history of web development and see exactly why the current stack is as it is
I have lived this history of web development. I remember when CGI was new and exciting. Now I see modern sites using literally thousands of times the memory and CPU to struggle to do things that were trivial even back in the 90s on a 486 with 8Mb RAM.
A typical document, say a news story might be 2kb-5kb in size. Why does the page need 5Mb of JS to deliver and display it?
So I am 100% confident in my assertion that the web as it is today is massively and needlessly over complicated.
It seems to me that you are describing click-bait blogs and the work of junior trend-driven developers. I have worked with plenty of clients who actually needed SPAs. Custom CRMs and ERPs, etc.
The quality front-end developers are not the ones who make small blogs or small corner store websites. It's agency developers working on huge projects. Those projects have big budgets on optimisation and page speed.
"The web" isn't an entity. It is a network of websites and applications. Some of them are slow and over-engineered and others are bloated excuses to display adverts. I can assure you that every single front-end developer I have worked with understood those issues and pushed for the right technologies.
You're right about the document sizes exploding but I think the real reason is the suits swooped down when they found that mere hyperlinked documents could actually be monetized into profitability. The rest is history. 4.4Mb for those 5Mb per news article is javascript that exists for ads and tracking, which in turn exist for monetizing.
It most definitely doesn't seem so. People build multiple solutions to nonexistent problems, or problems that are only relevant to google (which classifies them as nonexistent problems for everyone else). Then they push those solutions where they don't fit (e.g. SPAs for blogs)
I consider people getting real work done, without caring what anyone else thinks of their chosen tech, even in Excel VBA to be just as “real” as anyone.
To be honest, even if you appear a little 'elitist', I agree with your basic premise in that it's overly complicated for little reason and I do hope that one day we come to our collective senses.
I however disagree with the fact that I'm not a developer, and although I do it professionally I have little interest in the web outside of work.
Backend dev here. I tried to create a simple Angular app. I got into some kind of dependency hell on something simple. Going from Angular 7 to 8 broke some junk? Then trying to get Angular Bootstrap to work was hellish as well, especially when some kind of polyfills junk screwed up for IE.
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.
sorry you felt that way.unfortunately you dealt with the shit-show that is Angular + TypeScript, which is not beginner friendly AT ALL. I would ask you try using create-react-app, https://facebook.github.io/create-react-app/, and drop jQuery. JS is really awesome now and everything that was "in" jQuery can be achieved through standard library.
Well, choosing the right tool for the job is part of being any kind of developer. If you could solve the problem with no framework/lib/state manager, why go that way? The fact that those tools exist doesn't mean you _have_ to use them.
> they are not considered “real” developers by the rest of the community
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.
Well I'm not primarily a web developer, but I've worked alongside many. This neither describes any of them, nor would it be tolerated (or even possible to pull off) in any workpace I've seen. Self-puffery is admittedly endemic to contemporary tech/con-preneurism, but this is a quite ludicrous 'explanation' of a complex reality.
Masterfully condescending. I also appreciate the dig at JS via C++, which is perhaps the most complex programming language still widely used in the industry.
> If you lack a fundamental understanding what people are building obviously it seems overcomplicated.
Hi. I have a fundamental understanding of what people are building. Most of it's overcomplicated and the "web app or not?" decision's very often made due to hype, résumé padding, or making a project look more impressive to other internal folks. Some of it's justifiable as a "webapp" is truly a decent choice but still usually performs worse than is reasonable, indicating overcomplication under the hood—look at various Google "webapp"s performance dropping steadily over the years as features remain similar or drop off, and that's not even comparing them to older non-webapp incarnations which are universally much snappier (though usually missing some features, to be fair).
No, web development overall hasn't. Web apps specifically are largely fad-chasing vanity (manager, organizational level) or that, yeah. Which is cool because there's all kinds of dumb money flying around for them now—that part's been amazing. But it's not serving users well. Peacock feathers.
So a thing nobody wants or needs became extremely commonplace because JS devs (and only JS devs, I guess the Java guys have yet to discover this) realized they could invent some new frameworks and managers would gladly pay six-figures a head for them to play around with it?
I don't think the JS devs drove it, at least not primarily. I think they're largely eager to exploit the enthusiasm of others (and probably they should be) and I've seen it happen. I do think it's peculiar to the web. Most other GUI app ecosystems are content not to invent their own visual vocabularies over and over or twist every mundane little program or UI element into an "experience", for instance—I think that has something to do with it. It's the set of norms and (self-imposed, to a significant extent) expectations of the web, of the fear of "falling behind" (see again: peacock feathers). I think the background of the Web in bespoke brochure-type graphic design and marketing has an absolute ton to do with it.
I think a lot of the cost has to do with the underlying tech not really being that great for what it's being made to do, in concert with everyone feeling the need to try to be special in even the tinies little looks and behaviors. It's also where a lot of the audience is so will tend to experience oddities like this more exaggeratedly than other fields.
Your manager or project owner or whoever says "we want a webapp" are you gonna stick your neck out and argue against it? "But it's what google's doing", "but Gartner", but whatever. It's cheaper! OK, sure, here's my bill. It's absolutely follow-the-leader behavior, damn the cliff. And it works well enough that it does get the job done, eventually. It's just not necessarily doing the users any favors, or your bottom line.
Decision makers do strange stuff all the time because they think it makes them look better—and, to the extent and in the way they expect it to, they are probably right more often than not. This is just one example. Whole world's run by guesswork, personal quirks of taste or incentive, and blame-avoidance (follow the trends), more than anything else, from what I've seen. It's just people, running around doing funny people stuff, hoping no-one calls their bluff.
[EDIT] actually, look at Java Applets and, more so, Flash. Folks hated the way lots of those were used, but the worst and least-justifiable uses of them happened anyway, for a long time, because managers wanted the bling. That was, seriously, it. And developers went "oh sweet I can add Flash 5 and Actionscript to my résumé, I've been wanting to play with that". That's exactly what happened then. This is exactly the same thing, just much bigger. And in both cases sometimes the tech was used well.
> Your manager or project owner or whoever says "we want a webapp" are you gonna stick your neck out and argue against it?
The question is: what are you going to argue for instead? Not using the web at all is a non-starter, especially in the retail space where you'd get killed by a web-based competitor.
I don't know what your experience is, but historically my bosses haven't given half of a damn what tech stack I use. They care that I deliver on what I promise. Hypothetically, I could still be using PHP/HTML/jQuery but there are a great many reasons I don't and not one of them has to do with padding my resume.
I mean SPAs and near-SPAs. "Web apps". Web sites as in mostly server-rendered sites with HTML, CSS, and some JS sugar on top could sub in for an awful lot of "web apps" and improve UX, performance, maintainability, and development cost.
[EDIT] incidentally I notice you keep arguing against things I've not actually written.
It's because I've been trying very hard to understand what your contention is. The bits about peacocking and resume-padding are... unconvincing.
> ...improve UX, performance, maintainability, and development cost.
I don't buy it at all. As mentioned, I've done both professionally and there are reasons I keep picking React (or a hybrid ala Next) that don't involve a bigger paycheck or "peacocking".
It's usually companies or management/product folks paying for their product to have the peacock feathers. See also: flat/material redesigns not to improve usability—in fact it may make it worse—but to avoid "looking old", not because users complained or metrics look bad but because someone with a budget guesses maybe they might. Similar with choices to make fairly simple sites into heavy SPAs with questionable performance.
> It's because I've been trying very hard to understand what your contention is.
sorry, but if a front end interface is not easily understood, it is bad. its entire purpose is to have usability attributes, like predictability. SPAs break back buttons , new tab buttons, scrolling positions etc, the most basic stuff of web navigation
Chiming in with "yes". When you can't, it's a bug; routing frameworks like e.g. react-router render to normal HTML, and only intercept left-clicks to override default browser behavior for those specific actions.
Funny thing: in the last couple years I've seen way more back buttons broken because of backend idiossincrasias than anything else.
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.
The person who is writing their own game engine and doing everything from the ground up. They haven't shipped anything yet. They're five years into this with a few more to go.
For what it's worth, I can confirm that a lot of backend developers look down to frontend developers, but if you dig a little deeper you often (not always) see that frontend development is simply intimidating to them and they rather stick to what they know. At least in my country/region this leads to a lack of good frontend developers; good developers being those that apply well-known and established (backend) practices to the frontend.
> good developers being those that apply well-known and established (backend) practices to the frontend
100% agree with this. From my experience good front end developers are much harder to come by in silicon valley. We use a general coding interview process, and really struggle finding experienced front end developers because its a hard position.
When I have to touch javascript, I break everything, beg for help, then run back into my enterprise java code. This elitist backend attitude to me seems to stem from insecurities of us nerds. I personally feel inferior to front end developers, the ones I know are freaking magicians.
Most "enterprise" application backends are still written in Java (and probably C#) combined with a frontend based on Angular, sometimes Reacts or older technologies. I am not aware of any Node-based backend at any of our customers (medium/large German companies), except maybe for some smaller parts of the backend (microservices architecure etc.)
Ah, also, not sure if you were joking, but I don't think using JavaScript (TypeScript, that is) in both frontend and backend is a bad idea. Having a shared (domain) model can be a real boon. Admittedly, JavaScript lacks a few things that is offered by Java and the like that makes not yet fit for larger applications though (say DI, modularization and so on).
> I think this is it more than anything. People wanted to make the web complicated because it made them feel cooler developing it.
That is patently false. What happened is product managers wanted their websites to feel cooler to their customers, and work more like native apps. Developers then respond to the requests from the product managers. For example, charts that refresh data without a page reload when you click a button. The requirements get more and more complex, and the web was never meant to be an application platform. So you end up with what we have today.
This comment (and so many others on this thread) demonstrates such a complete lack of understanding of web development and SPAs.
Knowing as little as you do about SPAs, why do you think you would be able to understand all the intricacies of the problems they solve. Don't claim that people
> make the web complicated because it made them feel cooler developing it
just because you don't understand the issues.
It would be like me claiming that pro golfers wear golf shoes "just to look cool", when in reality, golf shoes probably offer some advantage that I'm just not aware of.
that sounds absurd to be true, even though it is also absurd how monstrous the javascript train has grown. And come on, C++ is not that complicated, i think ppl used assembly when they wanted to be obscurantists
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.
The worst example I can think of right now is: GMAIL..
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..
Wow, I had this exact thought the other day. I loaded the page, and just sat there and watched this animation on the screen. "What is it doing" was all I could think. All I need it to do is load the subject line of the first however many emails in my inbox. It can't be that complicated.
Nope, the content is loaded dynamically from their API after the rest of the page has loaded: https://i.imgur.com/Kxs9l7j.mp4
Sure, the list of my repositories is server rendered, but I already know my list of repositories. The thing I'm waiting for 99% of the time when loading github.com is to see if there's any new activity.
Sorry about the graphical glitches, blame nvidia or xorg or gnome or something.
Likely because the list of repositories changes infrequently, so it's a better candidate for caching. They serve what then can quickly, quickly, then pull in the naturally slower stuff later.
Like 5-10 years ago, writing.com updated their content from loading static pages to be more dynamic.
What they actually did was continue loading the content statically, then hide it behind a 1 or 2 second loading spinner that wasn't actually loading anything.
Seems like users have just come to expect spinners...
(I don't know how the site currently works, haven't been there in a long time)
Github is annoying. Some pages are SSR some aren't. The js is quite resource hungry so I tend to keep js off for github until I get to a page that needs it.
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.
This, this, this. Users didn’t ask for magazine websites - which should be serving up, y’know, images and text - to sit and spin on my phone while all the Javascript libraries load. Users didn’t ask for these things; we as a community just decided to foist it on them.
A lot of the slowest stuff on websites are trackers that are being foist on developers to foist on the users (if the developers even have control over the trackers, like with GTM)
Everyone(well almost) wants a SPA or at the very least non reloading pages. No one wants to reload the page with every action they perform or if only a part of the area on screen needed to be updated and the page was reloaded anyways.
> No one wants to reload the page with every action they perform or if only a part of the area on screen needed to be updated and the page was reloaded anyways.
That's what developers talk about. What normal people care about is the user experience: did an action take a long time, did it reset their context or fail into a confusing state, does the reload button work / can they share a link with someone else, etc.
That's an important distinction because using an SPA means an order of magnitude more code has to work perfectly before it's not a regression on one of those points. It's a lot easier than it used to be but, as we've seen over and over again, there are still many cases where people have a bad experience because the developer assumed everyone is fine downloading 5MB of JavaScript before displaying text & images, errors never happen, etc.
I'd say I am a fairly layed back guy on web pages, I don't run no-script, I just care for being able to navigate a web page reasonably well.
To me it just seems that most SPAs that I see, are either so small that the page load of a django app would also be fast enough, or they are so overloaded with stuff and advertising, that I feel like the performance benefit of SPAs has just been reinvested in cluttering more. Also, facebook, who built react, don't seem to have embraced the SPA.
I guess there will be a sweet spot, also on whether you build "pages" or "apps". Maybe there is a point of interactivity that warrants a SPA. I just don't feel like many websites hit this, like microblogging/twitter/etc.
> no one wants to reload the page with every action they perform or if only a part of the area on screen needed to be updated and the page was reloaded anyways.
well not 'no one'. When 90% of the page is to be replaced, a full reload gives better feedback and synchronicity.
Everyone (well almost) wants a server-templated site or at the very least a functioning back button. No one wants to sit and wait for 3 million lines of JavaScript to parse and run with every press of the back button (and probably not even get to the same state as before!).
Yes, I know there are some stellar SPAs that actually work. But I can't see why they're necessary 97% of the time and it really bothers me when I see a SPA where one isn't needed that breaks basic functionality like back buttons and right-click and all that other jazz.
If it's a traditional website and not an app, then I'm totally fine with it reloading every time you navigate to a new page or submit a form. Modern servers and browsers are plenty fast for full page reloads, as long as there isn't anything extra slowing down the load or rendering.
Most people say they are, but when you actually measure it you find engagement metrics are better for SPA sites, especially for ecommerce and social. Quite simply people spend more money if they can click fewer times. And thus we have things like infinite scrolling and ajax.
I've never met one of those users that care wether you reload a page or not.
I've seen people that care if you create a SPA that shows a spinner for 10s before allowing the user to get any of your content, but those are not as numerous as Google's webmaster tools makes one think.
I've seen plenty of people that are perfectly fine with a page spinning for 90s before getting any content if the page has the data they care about.
So, any out of context claim like "everyone wants a SPA" is wrong.
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.
You see that everywhere. In my field unless a dedicated statistican was a coauthor, chances are they picked the wrong test to use for significance. And if you look through their past papers you might find that they only use that one test that they always run, despite whether or not its relevant for their data.
In any field you can find people putting blind trust in tooling without knowing how the tool works or what its even intended for.
A solid idea well executed will beat a great idea poorly executed.
Sure, we all love to learn new things and/or push the envelope. That's what side projects are for. But when such things come at the expense of "the product" with a real user base than something as gone wrong.
"I love dealing with fast-moving things that are broken," said no user ever.
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?
Neither are the 'problem' with frontend development, but the reason why it has become a harder thing to do; that, IMO, is not necessarily a problem or a bad thing.
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.
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: Instead of waiting 20s for your truly interactive site with refine-as-you-type search bar to load, which, when finally loaded, will lag so much on my mobile connection that it is just plain annoying, I will use your competitor's site which loads within 1s and has a plain old <input> field for search.
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.
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.
This is such a lame meme. A community built an entire distributable developer toolchain from the ground up, in a completely modular fashion, and then get lambasted for it existing on disk.
Or maybe non-JS developers are just upset that they had to wait for Docker to be invented to do it themselves.
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.
Heh. I kinda felt: "hey, I agree with that", so I started asking myself why. What's the difference? Somehow, it looks like the difference is that on one side you have a very complicated problem but in a potentially well defined and bounded environment, and on the other you may have "smaller" problems, but on an environment so vast and complex that's kinda impossible to assert that you are doing things "properly". There are so many parts always changing at the same time!
For me, having come from robotics/digital imaging/signal processing and now doing web dev, I feel exactly this. My old problems were far more technical, but I could always form a complete mental model of what was happening.
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.
For me it's more related to why i became a developer- i love coming up with elegant solutions to interesting, challenging problems. trying to figure out why some inane CSS rule isn't working in an old version of IE due to some arcane non-compliant vendor-specific implementation just isn't very fun. (But thats also why i use frameworks like bootstrap and bulma.)
And everything carries over too. Parts of the DOM are historical or there to fix historical incompatibilities, there are 18 different ways to create your CSS grids, many of which are outdated...oddly enough, I had no problem understanding how/why observability works, but really disliked writing JavaScript :\
It's the difference between a difficult problem, and a complex one.
I think most of us here would find complexity more interesting.
Most difficult problems are difficult for uninteresting reasons (uncertainty about how some API works, having to maintain poorly written code, unclear requirements or business rules...)
To me, the difference feels like in one scenario you are solving problems fundamental to computing and the other you are struggling to wrangle with a dumb arbitrary API that someone made up. The former is much more exciting to me, and I suspect most CS people. That's not to say web development is all dumb arbitrary API's or you don't get to solve interesting problems, just much less cool/interesting IMO.
With the given example of working with threads, I don't get the feeling that the problem is somehow fundamental to computing. It would involve the somewhat-arbitrary threading interface, with decisions differing based on the API (WinAPI? POSIX? cooperative multithreading?) someone made up, with a set of locking primitives currently in vogue (mutexes? semaphores? lockless? message passing?).
Having done a lot of systems programming, my main complaint is that I'm almost always dealing with other people's models. I might be coming across fundamental problems in algorithms, but those are a tiny part of my work.
Known unknowns vs unknown unknowns. "I know how this should work but something's wrong" vs "how am I supposed to do this? Should I do this? Will this other thing change?" Hackers are fine with it, but system architects hate that uncertainty.
I think it's the difference between trying to keep a log cabin up and trying to keep a sand castle steady. The sand castle gives so much more anxiety and a fix threatens to break other fixes.
I know...and I kind of got the gist of it except I had a lot of trouble developing an intuition for it by trying to understand the history, other methods and just basically copying source code from existing websites...it's just my process for learning new things and it quickly gets overwhelming with front-end development...
If you took that exact table design and implemented it using flexbox (or even floats), the performance of the site would increase.
Tables require two (sometimes more) separate reflows. Minor changes in one cell can potentially force the entire table (and all its contents) to re-render. I also don't miss the days of slicing up images into tables for the performance and load-time gains either.
I don't know, but I would rather weld steel together in a sky scraper than figure out how to hang cabinets or even understand all the different types of crown molding.
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.
> rather fix a race condition on a multithreaded application
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 :-(
Everyone expects the frontend to be easy, especially non-engineers: "hey, it's just a box, and you can just resize it and center it just that way..", while non-engineers would just move away when you mention thread/concurrency/parallelism.
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.
Might that be simply because you are more interested in the one thing than the other? I can't come up with any objective measure of complexity that could show flexbox as being more complex than multithreading.
Really? I mean sure maybe the solution to your race condition is a thread safe queue... but if that’s not it then I definitely think fixing an issue with css is way easier... also The DOM api is finite and pretty well documented... MDN has done a pretty good job. Maybe something with WebRTC is trickier?
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?
That's the point. At no time did the engineer building the application make a poor choice. He/she made the logical rational choice to get the job done. It's the same thing for the tools developers. They each made their respective tools to solve a real concrete problem and succeeded. The problem is that everyone seems to be making incremental improvements and engineering choices that locally make sense, but when you zoom out and look at the whole picture things look absurd. We're incrementally improving ourselves to a local maximum that seems to be an uncomfortable place to be. There may be a better path that will lead to a better maximum, but we can't see it from where we are.
At the point that they chose to use all this kit and write "beautiful ES6". Write ES5, use a few polyfill functions, include the already minified mithril/vue/react js IF you actually are going to need dynamic DOM elements.
An XHR sweetener is included in mithril at least, but if not, it's only a few lines easily memorized, as you will do them constantly, it's also a good candidate for that library you should have made for all your projects by now, with that "byId()" and "byClass" shorteners etc... just an XHR you can pass a callback, url, and method to...
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function(){
if(this.readyState == 4 && this.status == 200) {
//do stuff to your dom, JSON.parse(return stuff) etc.
}
}
xhr.open("POST", "/some route/" + whatever, true);
xhr.send();
FormData(); would add 2 more lines to the above...
I see no point in all this front-end toolchain stuff trying to maintain an illusion that ES6 runs in most browsers.
Invariably maintaining false abstractions will not promote deeper understandings of the rather essential and basic "request response" cycle of HTTP.
It's not even pretty. Classes in JS? Gimme a break.
Show me the ugly truth and K.I.S.S. because life is short and we have better things to do in life...
Well, either that or polyfill. Transpiling to JS may be a product of other motives (Typescript, Svelte, Elm etc.)
While Ruby is pretty and all, I don't find that I'm enjoying the lie that is ES6, and don't even get me started on classes in JS, etc.
Bottom line, JS isn't my favorite language, but I'm not dying reading/writing ES5, (nor does ES6 look lovely when I know that it's lying to me) and the advantages outweigh the disadvantages...
I'm questioning a lot of the group-think decisions.
> Transpiling to JS may be a product of other motives (Typescript, Svelte, Elm etc.)
I'm not sure what you mean. Are you saying those tools should be avoided too or are you saying they are an exception to the "avoid complexity" rule?
>While Ruby is pretty and all, I don't find that I'm enjoying the lie that is ES6, and don't even get me started on classes in JS, etc.
I don't understand what you mean. What does Ruby have to do with anything? Also, what do you mean by lie?
> Bottom line, JS isn't my favorite language
Ok. That's fine. So what?
> the advantages outweigh the disadvantages
Would you care to elaborate on this? What would you consider to the be the advantages and what makes the complexity disadvantage outweigh them?
> I'm questioning a lot of the group-think decisions.
What is there to question? Don't use tools just because other people are using them, when you encounter a specific problem you want to solve, evaluate the available tools for solving it.
> State management? What is "a variable"?
I'm not sure what you're asking here. Are you asking why people use state managers when building js applications on the web?
None. That's the point. Web development is not simple. You don't have to always use the very latest super framework, but even the minimal setup for developing a modern website has quite a few moving pieces. If you remove any component from the list above, your development experience will become harder.
Apparently, when they decided developing for the web was a good idea. The bigger problem is that computing is insanely complex in the modern age. Developing for the web is on the cutting edge of that computing power. We're delivering full, non-native applications to computers people are carrying around in their pockets. And because they expect their applications to run like "real" desktop applications the UI of those "web apps" require a seamless experience. So web apps are real applications that require the same complexity in tooling as any another C++ desktop applications. Web developers are real developers. It would insane to create such complex tooling if we did not need to use it to build for those insane web browsers. Blame Sir Timothy John Berners-Lee for our current predicate, not us.
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.
Exactly this was one of the reasons why I built https://flems.io. Flems is basically just a scratchpad that begins with 3 files — .html, .css and .js. All the current state is stored in the URL, so sharing is simply done by sending the URL to someone else - true serverless ;) Here's a simple sample you can start out on with your nephew.
The fundamentals haven't changed. You can teach basic html in an afternoon, eventually making a static site or something in a few weeks. Thats how every web dev today learned to web dev.
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.
Very timely. As a backend dev I'd not come across the 'SPA' acronym used in the comments here. I wasn't even going to bother searching for it because swirly water in tubs. Now I know.
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.
The downside of using a code converter is that when something does break, the browser is going to show you the generated code and you have to map that back into your original code. If the generated code is ugly (hint: it's always ugly) then this can be a real problem.
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.
Source maps help a ton with this. Have never had an issue figuring out where the heck an exception came from when I've had source maps setup correctly.
So that's one source of complexity/difficulty: our "debugger" is a bloody web browser. And there may be transpilers between what we write and what the debugger sees as the source.
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.
As someone who hasn't done much web development in the last 10 years, it is mind-boggling how much you need to know in order to be a full-stack engineer these days. I tried to start a project a few months ago and just trying to decide on a technology was difficult. Npm, Gulp, Grunt, Webpack, React vs Vue vs Angular...I don't even know what half of these tools even do, why they're needed, not to mention the learning curve to get up to speed.
I got really jaded along with a few other things and let my skills stagnate for a few years and now I'm looking at jobs and I'm unqualified for all the half decent ones. I'm personally trying to switch out of development, but I kinda wish I had made an effort to at least understand some of the new(ish) stucc
I feel your pain. This is one of the few industries that doesn't value experience. Unless you're spending all your time learning new technologies, it's really easy to become irrelevant.
And there are like 20+ popular javascript (or Typescript, CoffeeScript, Dart) frontend frameworks to choose from (Vuejs, React, Angular, ...) several "native" solutions if you also want Mobile apps (NativeScript, ReactNative or even Flutter if HTML is not looking good enough) and there are like 10+ languages to choose for the backend development. And don't forget proper state management (Redux, RxJS, NgRx or Vuex). So if you plan to make a simple admin webpage you can either quickly write 50-line code in PHP or Python or some other lang. Or you can spend months learning TypeScript, webdev tools, js frameworks, Golang (+dependency management), java (+maven, gradle or some other tools from hell) and spend half a year on it. I have spent so much time learnig all that frontend and backend sh*t to find out "yeah it's nice and interactive but next time I should use HTML+CSS+AJAX)". Webapps are for teams of people. Frontend team and backend team. You need like 10 people to make modern SPAs roperly, also with all the proper CSP, headers and caching settings.
Try a minimal set up with create react app with typescript and react testing library. Go through the react and typescript docs. Try Formik for easier forms next. Axios for HTTP requests. You can then venture into client side routing with React Router and finally may be Redux for complex state management.
I wonder what drove this needless and pretentious complexity ?
The javascript ecosystem feels fragile and hacky, which spell bad prospects for its long term survival. It's more likely that jquery and PHP will survive after 2025 than any of the javascript tools mentioned in the article.
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?
> I wonder what drove this needless and pretentious complexity ?
> 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.
In the early 2000s Jakob Nielson popularised website usability through his books and his deceptively simple website useit.com. Big companies were paying him big bucks to have him simplify their websites much to the annoyance of the Java astronauts peddling n-tier jumbo sites. I often wonder what Nielson make of the insidious trend of using React & Angular for minimally dynamic websites.
My thought is it has to be a product of the language. Javascript can be used imperatively, declaratively, procedurally, and functionally, so it is. That coupled with the fact that it’s probably the most widely distributed interpreter so lots of people use it and ideas come out at a rapid clip. Then there are the vendor differences...
Most of the hiring is geared towards what do you know instead of how do you solve problems.
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.
Because a Web developer had $PROBLEMS problems, and he thought, "I know! I'll add an abstraction layer!" Now he, and the world, had $PROBLEMS + 1 problems. Repeat ad nauseam since the mid 90s.
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.
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.
Ironically, many actions are drastically easier to track on the server side. Frontend pageview tracking is trivially knocked out by ad block. Backend pageview tracking is impossible to block.
Wouldn't say that. With something like Segment it's easy to shovel data from the backend to any analytics provider you can think of. The majority of analytics providers have a REST api of some sort.
I think part of the reason so many of this type of article exist is because it seems the common expectation is that things should automatically make sense to us on first glance. So many products and tools are this way. But they are that way by design. The builders / inventors of those things hide you from the reality behind the scenes.
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.
It's not that complicated. There are only like 20+ popular javascript (or Typescript, CoffeeScript, Dart, ...) frontend frameworks to choose from (Vuejs, React, Angular, ...) and their popularity changes over time. Several so called "native" solutions if you also want fast Mobile apps and HTML is not looking good enough (NativeScript, ReactNative or even Flutter). And there are like 10+ languages to choose for the backend development. And don't forget proper state management client-side to maintain single source of trust (Redux, RxJS, NgRx or Vuex)! Webapps are for teams of people nowadays. Frontend team and backend team. You need like 10 people to make modern SPAs properly, also with all the proper CSP, headers and caching settings. And you have to transpile the code to javascript after every change and 1.5 GB of JS dependencies and tools with web-based editor like VSCode. But all that is worth it because it's so interactive and modern. :)
I like to read these things, because it feels so foreign to me. I started web dev around 2003 (stopped maybe 2010-2011), it involved a empty HTML file, perhaps only the few basic elements copied in, some hand crafted CSS, hand crafted JavaScript, a few ifs for Internet Explorers of the days, it was pretty manual, but one knew all the bits and pieces of the code.
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 :-)
It isn’t. With modern frameworks (e.g. React + Typescript + some CSS framework), it is surprisingly straightforward to build the front ends for highly complex applications.
This is probably a popular opinion on HN, but I actually agree. I’ve made things with PHP back when PHP was cool, and then when it wasn’t. I’ve build things with ASP classic, I’ve made my own ASP extensions, then moved to webforms then to mvc and now to core. I’ve made things with JSP and still have nightmares about beans. On top of all that I’ve used the JavaScript necessary to make it actual functional.
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.
This is like a neanderthal saying that fire is hard to build so let's eat the food raw. The time is now old man. The new frameworks are surely confusing (not complicated) to learn at first but that is because they expect you to learn a system by which the chances of you delivering a bad product gets mitigated as the lowest level components follow an accepted standard. You are learning a system, a new tool to aid in your work rather than starting from scratch every time. And if you say you don't start from scratch and have a system/set of components to reuse then, voila, you are just doing the same thing frameworks do, but in your own sweet way.
Anyone take the reasonable approach lately? IMO, it involves taking the CDN version of a framework such as VueJS and slapping that bad boy as a script tag in your HTML file. No webpack, babel, sass, etc etc.
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.
I tried it recently, my only other experience with SPA's was n Angular 1.x Cordova app. It was very easy to get set up, but I unfortunately scrapped it for unrelated reasons
Can you go into more detail? With Vuetify, I add my colors and generate a new theme. Hardly any new css is needed, especially with the grid systems that come with it. The compiled Vuejs gives proper errors in chrome developer tools, so it's been easy thus far.
Modern web development is so complicated because we fantasize that a nodejs frontend and backend will make everything better. It's like my product is better because it has more integration.
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!
I think there should be a new razor, we can call it the Apple razor because Apple is the most common case. Basically, when tempted to ascribe the decisions of a successful entity to stupidity, consider that you may not be considering all the facts and facets.
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.
Yeah, totally. You can open React Devtools on Facebook and inspect it yourself. Twitter uses React for mobile and judging by their HTML, they might be server side rendering React for their desktop site too, since there's the hallmarks of React (react-root) and CSS in JS.
Conversely, why are modern web apps so terrible? Take the Google GSuite Admin Console. This is what I called "Turn based administration" [throwback to the old turn based strategy games]. You start by loading the page and the 15mb of random javascript. Now click on something! Wait. ::Javascript stuff:: Incoherent error. Click Help. New documentation webapp loads 15mb of javascript to display some static text.
Hello, i am the popup from the button you clicked 57 clicks ago. i just arrived asynchonously and i m going to destroy your entire form. but don't worry, i will do a slide-hover-twist-and-twerk animation when entering
I think part of the reason so many of this type of article exist is because it seems the common expectation is that things should automatically make sense to us on first glance. So many products and tools are this way. But they are that way by design. The builders / inventors of those things hide you from the reality behind the scenes.
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.
... except that broken or ignored browser standards, and Javascript's lack of dealing with Timezone, for example, are not the result of complexity, per se, but of social inability: a committee or industrial consortium being unable to come to an agreement... kicking the can down the road in some cases, building-in complexity for ulterior motives in some cases by some parties, etc...
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)
The bar just keeps moving higher. Right now making a website that looked good a decade a go is very easy, but the cutting edge is about responsive, highly interactive applications. Additionally they are constructed by teams of people, increasing the level of complexity because of the need to share code while staying dependency-free. Client applications have become increasingly complex for anything that isn't a trivial website that mostly displays information. Complexity management on the client side I think is its own paradigm that is often not given enough credit and then people get surprised why their UI grows increasingly fragile while taking days to implement seemingly simple features.
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.
I think a lot of programmers forget the purpose of programming is for an end result. Instead, they focus on ever more complexity to feel superior to their peers. "Look what I can do" attitude. This reminds me of the Nasa space pen, when Nasa spent a million to develop a space pen and the Russians just used a pencil.
I think the structure of that post is a fitting portrayal of the structure of modern frontend development... And no, I am not one of those JavaScript naysayers. In fact, I started building my first Progressive Web App three years ago.
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.
I'm not sure if it's that complicated. I feel like you can do so much more with less these days.
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.
Although the article is about web development for the actual web, there is also a lot of web development that's not for the public web but just because using the browser used to be a simple alternative to developing a native GUI, especially if you valued portability.
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:
This could be rephrased, "Why is kernel development so complicated?" or "Why is FPGA development so hard?"
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.
Simply put, the web and all it's related technologies move at a much more rapid pace than Java, C++, .NET etc.
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.
Well..no one has to switch to React/Vue/etc.
You can still deliver well-behaved websites using plain HTML5 (CSS3 + jQuery), without all the bloat taken thanks to npm/yarn.
You can try to use SaSS or LeSS, to make your CSS files look neat and avoiding to DRY, but all the rest is pure bloat.
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.
I've been working as a full stack web developer for the last 15 years during this transformation and this couldn't be further from the truth.
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.
Chris Coyier did a fantastic talk recently that covers how "front-end" development has ended up subsuming a lot of functionality that was traditionally "back-end". Highly worth reading the slides:
I would greatly appreciate, given your 15 years as a full stack developer, that you explain what you are using today, and (hopefully) why. I'm also curious if you might have some vision for the future?
Like internal tools, consumer facing tools, content site, social site, etc. Is it an MVP? Rebuilding an old system? Is this a build it, ship it and move on? Or build, enhance and maintain for foreseeable future? What's required lifetime of it? What's the desired lifetime?
As well as resources. You want to use different setups if you are a single person compared to a team of 15.
Generally speaking the smaller the team the simpler the architecture needs to be. And the larger, the more isolation you want between pieces.
Personally I currently like Rails and React best. Both are fairly mature frameworks and work well together. Not to say there aren't better alternatives just those are the two that have worked best for me. There's so many good options that no one knows them all well enough to make a fair comparison.
I think Rust is very promising as a much faster alternative to Ruby and expect to switch over to it sometime in the next decade. But I don't feel the web frameworks for it are mature enough yet that I can justify a switch to it to my employer.
> Web development today is easy (compared to 15 years ago) once you know this toolchain
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.
I disagree with the first part (they are real developers!), but agree with the second. We have grafted an application platform on top of a document delivery platform.
I should probably rephrase that part, because yes you are right, they are real developers. But there is this misunderstanding that what they do is simple and it couldn't be further from the truth.
So off they go and try to prove that perception wrong by piling on the complexity.
I don’t think added complexity is a ‘feature’ us front end devs strive for. Instead, there are a lot of useful UX abstractions that are increasingly expected by users and are becoming extraordinarily tricky to roll on your own. Yeah there’s tons of extra crap, but the 8000+ projects in most node_modules has become more or less the standard library for that projects developer. It’s nuts, but JavaScript is the Wild West so it’s what we deal with.
i think it is more likely that "real" developers who started working as web devs missed the hierarchical ecosystem and built up one out of straws. Of course, that's a cargo cult.
What would an application platform look like that isn’t a ‘document’ delivery platform? In my opinion, the ability of your browser to be essentially the OS of the web was responsible for the second great explosion in usefulness of computers (the first being the PC itself). Mobile apps were the third, but it’s unclear to me if there’s any benefit to rewriting many (most?) web applications as desktop applications. Discoverability, complexity and debugging costs all go up in such a world.
It's hard to imagine given we've been stuck in this world for so long. However, I have to believe there is a better way. Building an app with HTML/CSS/JS just feels like a mess. I'd start by looking at some good ideas from the past... Sun NeWS perhaps.
Sure, I do. And it doesn't seem that people that still have to support Internet Explorer have a much easier time considering that they seem to have settled on using a whole additional layer of abstraction !
It really comes down to ease-of-updates. Web apps are trivial to update. No build / cross-platform / deployment issues that you encounter with native apps.
Velocity of updates is also important. If I update a package, it can take weeks, months... maybe years... before end users update. If I update a web site, it's instantaneous.
there is a UI framework on top of a document platform, running on a VM inside a browser program running in a sandbox of a host operating system . Occam would be furious, and i think this extreme duplication of UI functions is bad for the environment, bad for the users' nerves and bad for the MTBF of computers.
And we've been using them that way for a long time. The reason is it's so simple to deploy an app, no more developing cross-platform apps for Windows, OS X and Linux along with installers for them. I remember working on simple apps where the installation and deployment took longer than developing the app itself!
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.
(shameless plug) Just for kicks I wrote the client side of https://watch.ly/ without any frameworks (but used less/ejs/express).
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.
Why? Because most programmers are lazy, arrogant, self-serving children.
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?
I've refocused on web development in a new job after six years of being mobile dev first. To me, the answer is that design and user expectation got more complicated. Look at what was considered a state of the art web page 10 years ago, and you'll find the UX wasn't nearly as nuanced as today. Combine that with polyfills and responsive design requirements and it's just as complicated as a native app, and look how big those things are.
The modern web development also turned into app development to emulate functions that is on the desktop applications. That is what is bring ing the complicity to the web.
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!
Awesome! I had quite the experience setting up a react app workflow with a friend. If you don't get your versions of tools to all line up or you use a tool which is slightly unconventional, or sometimes if you're developing on not-Mac, things can go very wrong very quickly. Nice to have a post overviewing how to pick and choose (and why you shouldn't do that anyways).
In 2012 you were building sites and even applications with a stagnant language (JavaScript) that lacked any module/bundling support while having to support multiple browsers with differing standards. Routing, state management, dependency resolution, etc. were handled on an ad hoc basis if at all.
The current complexity is a result of addressing these issues and doing so at a rapid pace.
In summary, the OP concluded frontend design has gotten easier though abstracting browser compatibility (i.e. compiled javascript frameworks).
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.
It isn't. Unless you make it complicated. Developers spend time making things complicated. And then more time complaining that things are complicated. Followed by even more time "solving" what is complicated by making it complicated in different ways. Repeat. Yawn.
Because building and deployment are not straight forward. 10 years ago you could have some PHP script, some HTML templating... Upload the whole thing via FTP onto some LAMP hoster, and you could show it to people. And the hoster even had an MySQL database preinstalled if you needed it.
It took me some time that the author is female named Victoria Kirst with 6 years at Google and 1 year teaching at Stanford CS193X http://web.stanford.edu/class/cs193x/
Among various reasons:
- Most people overcomplicate things, in general, not just in web dev.
- Not using the right tool for the job (I often run into sites displaying static content where they are using a bunch of frameworks and unnecessary code)
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.
Because software engineers want “growth”, and for most of them growth means learning/creating new technical things, and learning/creating technical things means more complexity.
I always think it would be a huge success if somebody could deliver the same ease of development that VB and Access had for the desktop. There are some I have seen but they all are not as simple as VB and Access were.
i was just thinking about this yesterday. The khan academy website became so complex in its layout. I think the old school web will make a comeback. Things are too complicated these days
The more developers who work with an ecosystem the more complicated it gets. Therefore the most developer common job (Web Development) gets the most complicated ecosystem.
Speculative answer: “because it’s a technical solution to a social problem, and therefore can only mask the symptoms and not address the underlying cause of the problem.”
For somebody who just wants to pick up a useful programming language/set of languages these days - should I engage with modern web development or avoid it entirely?
It's not the tools, it's the 'Full Stack' title. If you want to be a 10x employee, be a full stack architect you need to know all of it.
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.
The problem with that, is that flash even as an IDE was not really suited our new responsive web. Its not really good for content or development of anything other than games, animations and ads.
Did you ever develop with Flex? MXML and CSS + ActionScript was a great way to design webapps, and if phones actually ran flash, apps and components could be just as responsive as anything modern. The closest JS ever got to it was Angular 1, but then the Angular folks changed course and whatever version it's at now is very different.
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.
Actually I must admit that I never really gave flex a chance. Don't get me wrong, I miss the flash days as well, its actually kind of sad that open source player / recompiler projects never really got anywhere.
nice article; I don't really find it that complicated, only extremely useful.. In fact without it i would be quite the sad panda especially as I'm still required to support IE11 for foreseeable future in many large apps. But ya, if you don't need it don't use it. I'm sure as heck glad all the tooling I have now exists though!
Its complicated because people make it complicated. Instead of following trend bullshit and self-justifying tooling insanity start with the a solid foundation and build on it one tiny layer at a time.
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.
I actually wrote a thingo on this recently. Modern front end has essentially the exact same challenges as a server which provides its API with sockets/websockets/events.
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.
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.
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.
To someone attempting to return to web dev after a break of a decade or so, my normal response is incredulity at the absolute horrorshow that's arisen. To me it's a complete towering, teetering mess of differing approaches, needlessly heavyweight frameworks, terrible decisions, and inefficiency. This is probably the ultimate cliched comment but I honestly cannot understand how any self-respecting developer can work with this xxxx and look themselves in the mirror.
I know it sounds unbelievable, but plenty of web developers ignore that whole show. It just doesn't seem the "upgrade" is worth it until something better comes along.
It's complicated because nobody knows how to fix it. There's no formal definition for a "good design" or a "better design", so people keep iterating over the designs not knowing whether the new design is actually better or worse.
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.
Because people have no time or incentive to make it simple. In fact, the incentive is to make it as complex as possible so you could charge more (and then charge more still for maintenance), and create a moat that "lesser" developers won't be able to cross.
Because people with degrees brought their backend complication to the frontend when they realized they could only get money as a web developer. Now we're all fucked.
Because we're no longer making websites, we're making apps.
Sure if you just need a simple website, make it from scratch, but good luck maintaining a full blown app using jQuery.
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.
I disagree with your ending note. I like React and have been using it professionally for over 2 years, but I wouldn’t recommend anyone to use something just because it is an industry standard. At my work, for example, the upper management is now convinced that microservices are going to solve all of their current maintainability problems, while the fact is that there are a lot of employees that write shit code, who will also develop shit microservices.
My sole reason is to point new developers to the skills that nets them the most job opportunities.
Learn the most popular (and imo the best) framework first.
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)
I might pick a nicer phrasing for your last point: if your team is not good at clean architecture (separation of concerns, conceptual model, etc.), microservices will “solve” that in the same way that adding gasoline solves a fire. If your team has gotten better at that, however, it might be a good strategy for migrating pieces out of an old system.
You can’t get simpler than Python and tkinter (or just strait TCL/tk.)
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.
great, now you have a native client but now your customers will expect that it works offline, so now you're building a sync system for your app.
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.
Oh sure yes, 90% of the things people want are really just a few HTML forms and a back end.
My point was that desktop development isn't any harder than web development. Most of what you've mentioned involve adding features and the same features would be just as dificult to implement in a web app.
>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.
I think most of these demands are misunderstood.
RE: "syncing": Most people just want to work with their data offline. Traditionally this was done by interacting with the filesystem rather than a thick client manipuliting the state on a server (like many modern web apps are.) There's no need for "syncing" or complex protocols.
Edit: To be completely fair this doesn't anything for the front end, unlike create-react-app. I'm not a web developer so I don't really have a dog in this fight.
I guess my point was it's really easy to get started, and it's a really common misconception that starting a SPA is difficult. It's just as easy as getting started on any other toolchain, if not easier.
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.