Why is modern web development so complicated?
vrk.dev
vrk.dev
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.
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.
Remembered me of this cognitive bias: "Overestimating Our Own Importance" [1]
[1] "Psychology of Intelligence Analysis", Chapter 11. Available at:
- https://www.cia.gov/library/center-for-the-study-of-intellig...
> 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.
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.
The new thing must be at least a bit better than the old thing. Over time those improvements compound and you end up with this: https://www.youtube.com/watch?v=fPF4fBGNK0U
Also the name of the little funny book where you will find the origin of "bikeshedding".
More pleasant and timelesd a book than "bullshit job", IMHO.
But, you know, I guess we'll find out sometime in the next couple years.
I wish the IoT space weren't such a dumpster fire. I should go back to my plan to run a website on a cluster of nanoPi's.
Not to mention, saying any of those things would make you a "bad culture fit" and potentially break the "no assholes rule" if you argued the point.
I 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.
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.
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 sure as hell do.
Joe Sixpack doesn't give a fuck either way.
Thus, growing pains and overly complicated frameworks/plugins/other bits slapped together to address the core issues which ballooned the complexity. But we all knew that.
What's more impressive is that things are getting less complicated. Browser monoculture, while bad for the freedom of the web, is going to simplify things radically. Only having to target rolling releases for Firefox and Webkit? That's a dream from a cross-plat support side. Also javascript is actually pretty good now. Webcomponents once Chrome 77 drops and Firefox matches parity will finally be production worthy, and they're actually quite easy to build. I've been making static sites with them recently and it feels so much cleaner than going with a React or other component library approach that uses a vdom. The HTML is readable again, and there isn't any needed compilation step or crazy npm dependencies.
While it will never be as easy as it was back in the mosaic days, web dev is simplifying.
Over what timeframe? While it certainly had its own issues, the HTML5/jQuery pairing easily fit into your head. Notwithstanding the benefits, React, packers, routers, and the 10 other things you bundle, is a cognitive load. Doesn't help that the routers and 10 other things don't come with React, and so, choices vary across teams.
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.
- 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.
- Use a RPC-like API (e.g. https://github.com/reframejs/wildcard-api) and only use REST/GraphQL if you need to expose your data to third parties.
- Use server-side rendering/routing if your app is mainly about content (a blog, a newspaper, a e-commerce shop, ...).
- Use client-side rendering/routing if your app is mainly about user interactions (a music player, an email app, a graphical editor, ...).
That's what I'm trying with Reframe: https://github.com/reframejs/reframe
What's changing in Chrome 77? A caniuse search for "web components" does not turn up anything that's not old news.
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).
As well as the implementation status in chromium: https://www.chromestatus.com/features/4708990554472448
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.
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.
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.
I’m not sure ActiveX, ASP, and SQL server were ever hipster. You’d be doing the world a favour by re-writing these apps.
Literally doing a favour: there’s never any budget for it.
MVC PHP frameworks are very nice and they don't move as fast as those javascript frontend rendering.
Also the ORM deals with any security problems and most framework deals with other security deals too including session handling.
It takes a massive amount of resources to develop your own security, your own data access without any ORM tools, not cause memory leaks, properly disposing of resource.
I'm all about creating reliable applications, but a good framework is a great tool.
Just because the framework uses them by default it doesn't mean they can't be used separately.
You can use Razor Pages or a router like Nancy[1] without having to roll your own ORM or View Library.
It's php. Everything is trashed once the http request has been served.
I think it's way nicer. I much prefer environments like Sinatra, Express or Flask than full-blown MVC frameworks.
There were so many ways of structuring your codes. I find myself constantly rewriting the code to adapt to a new way of organizing codes.
I personally prefer a somewhat opinionated framework.
But I understand that there is a pro and con and a need for a barebone/slim framework versus a featureful framework.
I actually moved from flask & vuejs 2 from last year to phoenix & jquery.
> 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.
It depends way more on the organisation or team developing it than on the libraries you use.
In other words, "I can choose the correct tool but still fail from poor approach of problem."
Entire classes of bugs simply don't exist in better languages.
I think it should be a more widespread idea that people should aim to leave a company with a net-negative `cloc` contribution.
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.
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.
Erase existing software, so we have less amount of shit software.
I'm actually applying that technique at work with great results (really!)
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.
The best patches only have - lines :D
Placing the blame on him when you were the one being hostile is hostile.
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.
jQuery just changes the DOM. It gets very difficult to keep the DOM in sync with the JavaScript backed data when there’s multiple moving parts.
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.
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 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.
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.
le sigh
*And you BETTER be using the minified version for production.
Good or bad depending on context.
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.
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.
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.
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.
> 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.
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".
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.
they've been waaaaaaaaay longer than CS/SE
they do not change so robustly & fast in short peroids of time.
>We can't even accurately estimate the cost of a complex project given our choice of tools
Let's do not pretend as if that was limited to our industry.
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.
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.
Nah, this isn’t really true. Consider all the technology that came out of WW2: digital computers are contemporaneous with jet engines for example.
> 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.
Would love to see that. For companies determining what's worth what, this would be great to see, even just for the format.
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 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.
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.
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 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.
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?
[0] https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.h...
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.
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.
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.
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.
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.
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.
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. ;)
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.
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.
Anyone engineering hypersonic missiles would easily dispute that.[1] Or submarine-capable quantum communication systems.[2] [1]https://www.nytimes.com/2019/06/19/magazine/hypersonic-missi... [2]https://www.realcleardefense.com/2017/11/04/quantum_communic...
[1]https://www.scmp.com/news/world/russia-central-asia/article/...
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.
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.
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.
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 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.)
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.
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.
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.
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.
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.
Shifting project and business requirements, scope creep, poor design choices and lack of competence all contribute to what makes bad 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.
Isn't the saying, YAGNI (You're not gonna need it)?
(Aside, flip the contraction to get the acronym - "you aren't gonna need it")
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?
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....
The point of (well-designed) frameworks is that they act as “rails” and make it difficult to make bad decisions.
They also make it easier for people on a team (or people who maintain the project after you leave) reason about your code.
Therefore, as far as I’m concerned, not using frameworks is a huge red flag.
edit: bring on the downvotes!
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.
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.
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".
Some people are just like that I guess.
Edit: found it - "How We Engineered CMS Airship to Be Simply Secure" https://news.ycombinator.com/item?id=13905055
It could be a signal of sloppyness or writing it in vim.
> 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.
You can always import libraries into your project for the critical stuff, instead of using the whole framework.
Even Laravel itself imports third-party libraries such as Symfony, which you can use in your project without importing Laravel.
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.
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.
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 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.
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)
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...)
Not entirely related, but there is usually the incentive to at least say this for a new person/team coming on because money. Especially for frontends, the new person/team we talk to when going into an existing project, says that it has to be redone because it's 'not up to standards'. That is not because it's not fine and maybe even beautiful; it makes more money to rewrite it. And job security perhaps too. So when someone says something is garbage, I need to assess the reason why; is it garbage or does the person saying it benefit from a rewrite somehow.
When was the last time you had a go at CSS? So much has changed since 2017. You can chuck out the pre-processor junk and just use CSS variables and CSS Grid. Productivity is 10x.
You can even keep it simple so that a page just loads the CSS it needs instead of some 40,000 line ball of junk.
Same with templates, if you are using CSS Grid you don't need the sea of div containers, you can just use actual content elements from HTML5 and never use a div.
Pseudo-selectors mean you don't need spans. You can get pretty things done without the markup in the document. Once you write HTML this way you wonder what on earth people are doing with these impossible toolchain and impossible HTML web pages. Regular development from about five years ago with frameworks and jQuery nonsense just looks like hacks.
Many government and healthcare organizations STILL using Internet Exploder, presumably until its 2025 end of life:-(
Oh you sweet summer child...
PS - this “child” started working as a developer, at least part time, back in 1985
C++ eventually passed into a bad memory, and so will MSIE.
As far as I know, Microsoft plans to keep IE11 around as long as Windows exists.
https://en.wikipedia.org/wiki/Microsoft_Edge
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.
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?
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.
And the hiring manager who can’t find anyone that doesn’t want to pad their resume for the same reason.
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.
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.
"After me cometh a Builder. Tell him I too have known."
But it could have very easily gone the other way. If your website had complicated validation rules on multi-page forms (not unheard of in healthcare) the site would be better off for some basic state management interacting with a standardized authentication/authorization framework that you didn't have to write.
From what you're describing, it sounds like you did right by the client in this circumstance. But sometimes, it does have to be complicated. And in those circumstances, frameworks and javascript (unlike garbage) have an important place.
jQuery would fit well here.
onSomethingChanged() {
$('#foo').prop('disabled', true);
$('#spinner').removeClass('invisible');
$('#error-1').prop('hidden', true);
$('.buttons').hide();
if (value) {
$('#btn-2').show();
} else {
$('#btn-2').hide();
$('#btn-3').show();
}
// etc ...
}1. Render model from your JS object.
2. attach events
3. Change model
4. Go to step 1
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.
I would like to trade out AngularJS for Vue someday, though.
Sites like HN and Stackoverflow have a vastly different audience than most bread-and-butter sites, and tackle different kind of issues.
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.
You can write bad apps in any language and environment, similarly a site/app is not bad just because it's done in Y.
It almost never has to be complicated. People just enjoy making it so.
Looks at their inventory management system
Also I'm 97% sure I could own your site in under a day, based on how home-baked you just said it is, and I'm garbage at pen testing.
Healthcare site, you say? Jesus Christ, I hope they have data breach insurance.
The internal and external security audits already performed by the billion-dollar healthcare company in question disagree with you.
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?
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.
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.
https://www.php.net/manual/en/password.installation.php
"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 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.
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.
A lot of bad software engineering going on in these comments, downvotes don't change that...
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.
It does, actually: https://www.php.net/manual/en/intro.password.php
If it's simple enough and they understand PHP well, it could easily be better.
Any reason they liked it in particular? Faster? Better/cleaner UI?
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?
Popular frameworks are not silver bullets, but apparently it's popular on HN to think so.
If I'm the next developer I would thank him.
Ever deal with 5 versions of jQuery that are conflicting. Trust me life is easier in vanilla php.
Consolidating versions of jQuery.
>If I'm the next developer I would thank him.
For what? You wouldn't know anything about the previous site implementation
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.
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.
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 :)
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.
Agreed in general, but there are better free/libre choices. I don't recommend these for greenfield projects.
I'd replace PHP with practically anything written by grownups. (Django, Rails, etc.)
I have been much happier professionally since that day.
And both probably beat out Node.js
But other than e-commerce, yes, Django or even Rails is my preferred choice.
- PHP: A few years ago I heard about how PHP was needlessly complex. I wonder what the recent status of the programming language is. Specifically, do experienced PHP programmers stick to a subset of PHP, as in "PHP: The good parts"? (similar to "Javascript: The good parts"). (side note: As a diehard python person frustrated due to latest versions becoming bloated in features, I fully acknowledge that I'm in the "Python: The good parts" camp right now).
- MySQL is owned by a company lately. I wonder if PostgresQL is clearly a better alternative?
See: https://phptherightway.com
Modern PHP development comes in the form of loading dependencies from Composer/Packagist, rather than offloading a lot of bloat to the language. Lots of things have been deprecated (and even removed, like ext/mcrypt).
Some of the defaults like globals being turned on by default led to security holes. How people were creating sql statements at the time concating strings led to sql injection issues.
There were never any bad parts . There are new features like the spread operator that are newer and not available in earlier versions. I try to stay away from them if I think the application will need to run on older versions but otherwise I feel like I can use any feature.
Postgres needs to run under a specific os user. That alone makes it a poor MySQL replacement
There 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.
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.
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 have also written heavy amounts of Python and Java at various points in my career. A few other languages too.
PHP has many, many bad spots. It's easily the ugliest, clumsiest language I have been paid to use.
It's slightly dated, but this is still the best summary I know of:
It has different philosophy, and needs a little getting used to, so it's not as easy as simply lift-and-shift
However I would be concerned about a couple of things if this were me and I was doing anything beyond the absolute most basic web app:
- long term maintenance. Doing something only you understand and only you can maintain (that job security you mention) is a bit of an unprofessional dick move IMO.
- if you need to get other people in to help, you now have to spend more time training then up on your custom system that they don't understand and keep an eye on them to make sure they are doing it right and not introducing security issues
- When your client wants to integrate with some common third party thing ("hey can we put Google maps in here?"/"we need to integrate with stripe payments") you'll need to reinvent the wheel from scratch to do it using your custom system rather than just use a well-supported off the shelf library.
- you'll need to stay 100% up to date on all security issues/approaches/classes of vulnerability to make sure your custom system is secure. Your audit was ok this time, but everytime you make a change to your custom library (e.g. to support Google maps or stripe) you're now going to need to go through the audits again to be sure you've not opened up any new security holes (and perhaps new ones you've not ever heard of because you are only working in this weird little custom system/thiefdom for the past 2 years)
- how to support the INEVITABLE requests for extra features that require something client-side that cannot be easily done with only PHP and static pages. It is not the 90s any more - the cat is out of the bag regarding interactivity ... the requests for client-side nicities that users are used to in other things WILL COME! Clients always want more! :-)
Still anyway I guess you don't need my good luck wishes as I am sure you are correct and that you really have out-thought and out-coded all of the well-supported and well-funded frameworks that have been built by many thousands of people and have been battle-tested in the field for years (e.g. Laravel, .net MVC, struts etc). Because otherwise if you hadn't totally out-smarted the entire industry, I'd be shitting myself and checking my professional liability insurance about now.
A decently structured PHP application is often maintained by nontechnical people with a limited understanding of programming but they can get by with just a text editor and a codebase. I have not come across any nontechnical person who could easily get a react/modern js framework pipeline going to do a small change, not to mention dealing with npm changes. I would almost feel like it would be a jerk move to leave someone without a technical department a pile of react/npm soup right now.
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.
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.
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.
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.
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?
Yes, and it takes less than a second (checked in Chrome performance console) to do it. I'm happy with that.
Also hacker News is one of the simplest use cases ever.
Note that 95% of Facebook by usage (scrolling through feed, liking and commenting) doesn't have much more functionality than HN.
I'm not sure why you need a modern "looking" site since JS is about the functionality not the looks.
Wait, PHP is not garbage?
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.
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.
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.
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).
I used to code in ASP and PHP back in the day, and that approach made a lot of sense. You'd have things that run on the server, and then those things throw out a website for the user to interact. If there's a need for reactivity, use some JS, but basically it all goes back to the same server program. I always found that this approach was good enough. You could do a lot, heck, I even wrote a browser game back in the day. Most importantly, it was simple, and it led to great web pages that would always work and could be used as such. No JS, no cookies? No issue, your code would just deal with it. A button was a button, and link was a link, and your browser did the rest. Text got sent as html, pictures were loaded or not depending on your preferences. Everything got faster and faster. This was years ago.
In the meantime, I stopped doing web dev.
Suddenly, in the last ten years or so, I noticed that websites became bad. The whole web just seemed to regress. Everything was JS, everything became single page, and if you didn't enable every single function in your browser, or if you pressed the "back" button, or reloaded the page - basically if you did not pretend that the website's UI was an actual native program - then everything breaks. News sites stopped loading text or images halfway through, buttons stopped working. Links were not clickable. Pictures would not show up. LOADING bars and circle-things appeared on websites that were already downloaded on my computer. Registration forms did not load default options, choice elements were empty. Once the page was loaded, everything was sloooooow. Scrolling became "different" and often laggy. Websites would load, then do something in the background to reload into garbled messes. Printing didn't work correctly. It's like Flash websites of my day (that everyone know were terrible and had very few good use cases) became the norm, but without Flash.
What happened to the internet? Why is everything garbage? Did all web developers die out?
I went back to make a simple website for myself. Reading tutorials, it was clear I had to use some framework. It was recommended to use JS, install some sort of server application and database, then a framework on top of that, and then something that runs in the user's browser. But everything was its own programming language, with no common denominator. You'd either need a PhD in JS and server development, or be happy to buy in to some framework that was usually not even very good. I did not understand anymore how web development works. I did no longer understand how the websites came to my customer, what the server did, how and when it did it... and everything was hard, even though this should all be really simple. And what came out was just... bad.
I went back to using simple web dev tools if I need to, and thought "well my needs are just not so advanced". But given that most websites have become so terrible, I just can't help but feel it all went wrong. Whoever thought up this frameworks and JS revolution was probably really smart, and there are probably some really good websites out there.
But I hate the internet now, and I don't understand web development anymore. I'm not even that old.
I'm really glad to see that this no nonsense approach catches on.
This is my problem at the moment. I have a nice static site, but I'm facing demands from the marketing team to use Wordpress so that they can make copy changes to the site without having to go through a developer (or learn any HTML).
The funniest comment I have read on this website.
One of my clients was an airline. He asked if we could track the usage stats of his in-flight entertainment system (just stats, no PII). I thought about it and said yes. Even I was amazed I said because a decade ago it wouldn't be possible. I got it done with service workers (because flight wi-fi isn't a 100% always on connection).
It was a boon for me because I made a lot of money on that project and I needed the money. It's also a curse because every browser has all these invisible code running behind the scenes whether you want it to or not.
I miss those days where everything was just a bunch of tables and default system font-powered webpages with plain blue links. No CSS, no popups, just html and pure content.
As a developer, I can say that it is designers and product owners who push for the needless jazz in many many cases.
You mean like HN? You 're not missing it. The old web never left. It's still here to catch all the misguided cloud walkers when they fall.
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.
Someone else mentioned SPAs. I 100% guarantee that no user in the world ever wished for their “back” button not to work as they expected.
Calling themselves “full stack engineers” is another symptom of this.
It 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.
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).
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.
Some SPAs are cool. Easyeda.com is pretty cool.
But also: storing information about a page in the URL is pretty cool too. It makes it possible to link to the page, for instance!
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.
I think people who don’t understand the web talk it down to make themselves feel superior.
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.
Ended up just linking to it directly to the jquery and bootstrap CDN...
It's been a long time since I did any kind of major front end work. I think it will stay that way. I don't do enough work with it long enough to really "get it" and retain it.
Pahahahahahaha. There is no group in our industry with a bigger chip on their collective shoulder than "C++ guys".
I mean, you only need check out all the vulnerabilities in said C++ software for verification of that fact :)
I think what you're trying to say is that you don't consider 'webdevs' to be "real" developers.
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.
Well, a lot of them aren’t - until recently, a lot of front-end developers were actually graphic artists who were more skilled in photoshop than software development (not to knock that skill, it’s a useful one!). It doesn’t help that 23-year-old MBA “unicorn startup” founders have bought into this pipe dream model of software development where a couple of eggheads in the unlit server room develop algorithms that the $10/hour mcweb-developers cut-and-paste into beautiful templates.
This opinion invalidates the rest of your post. 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).
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.
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.
[EDIT] incidentally I notice you keep arguing against things I've not actually written.
> ...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 because I've been trying very hard to understand what your contention is.
I appreciate it. Seriously!
Bootcamps are something that grows out of this desire to pad your resume with newer tech.
I build SPAs as part of my job. Good SPAs do not break the back button. Insisting they do is silly.
This is funny because C++ used to be considered a shining example of this. Software is a flat circle.
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.
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
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.
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 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.
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.
Switch your gmail account to Basic HTML (https://support.google.com/mail/answer/15049) and see how the SPA version isn't any slower but in fact much more pleasant to use.
"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.
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.
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.
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.
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.
well not 'no one'. When 90% of the page is to be replaced, a full reload gives better feedback and synchronicity.
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.
In fact, I'm pretty sure Github is rendered server side for the first load. You shouldn't be seeing any spinners. I'd check if I wasn't on my phone.
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.
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)
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..
It's not that difficult if you're a decent programmer, and if they're not then why hire them?
Nah. Nobody cares. I think that bears repeating...Nobody cares.
My mum has __never__ said to me "I love React" or "Isn't Bootstrap the best." But she __has__ complained to me about a site/app being buggy, confusing, difficult, etc. I've said the same to myself too many times to count. I think we all have.
A couple months ago, I read an article about (frontend) tools and how important X, Y and/or Z are. The author's product had a repo on GH. There were 700+ issues. All I could think was, "Apparently those tools have given his team a false sense of security. Looks like they've bitten over more than they can chew." I filed the article under: Just because you can, doesn't mean you should.
Years ago, I remember reading an answer on Quora (when Quora still mattered) that included:
"A fool with a tool is still a fool."
I don't think I'll even forget that line. It's so true. I'm not against tools. I'm just not in favor of those who claim tool X, Y or Z is a panacea.
In any field you can find people putting blind trust in tooling without knowing how the tool works or what its even intended for.
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.
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?
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.
Don’t get me wrong — being a skilled developer (in the traditional sense) with significant competence in frontend development is extremely attractive. But this profile is actually quite uncommon imo.
I have to ask, do you really think the problem with frontend development is about performance? That FE is hard because of the code is executed on unknown machines?
This does not resonate with my experience.
FED is now about solving harder, 'more real' problems, and performance is one of those problems. Writing performant code for -potentially- old machines, mobile devices of various kinds and in the end different browsers, requires a different level of expertise. This is why I'm a bit triggered by the 'wandering pixels' and 'cant do css' comments, and I do apologize for getting a bit intense.
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.
Recommended reading:
- "Responsible JavaScript: Part I" by Jeremy Wagner (https://alistapart.com/article/responsible-javascript-part-1...)
- "A JavaScript-Free Frontend" by Matt Reyer (https://dev.to/winduptoy/a-javascript-free-frontend-2d3e)
Disclaimer: I'm from Germany, but have a 6-y/o Android phone and live in a rural area with poor EDGE connectivity (~50kb/s). Most "modern" websites don't load/work for me.
Here's my hot take: JS is good and has made the web better.
Not every site needs to be truly interactive. Not every site needs JS. Unless you're building a 3G+ or desktop-only web experience, use it responsibly.
But does the website you're building need to be interactive? Usually not, unless it's a webapp. (Maybe for form validation but that's pretty much it.)
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
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.
Or maybe non-JS developers are just upset that they had to wait for Docker to be invented to do it themselves.
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.
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.
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...)
Thankfully with modern browsers nowadays you can open up their dev tools and use them as a 'scratchpad' to play about with CSS.
Breaks it down into simple pieces and explains with clear diagrams.
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.
And while my upstream devs will be happily accepting my patch because it quite obviously visually fixes the problem, you'll still be explaining to your upstream why their "perfect" ad hoc threading abstraction is indeed broken.
I 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.
I think this would be true if the race condition was in my own code, but doing this against another codebase would be pretty brutal...
Part of the reason Flexbox/DOM is painful is that it's very much "someone else's view/code/logic/etc."
You can fix race conditions on single threaded JavaScript code now we have async (and promises): it scares me how little this is recognised as a downside and in my experience few people are good at recognising or writing code that avoids race conditions (I have seen competent programmers in denial about the risks).
Before async I found race conditions in popular (and well written) JavaScript code that used setTimeout().
Personally I think anyone that enjoys chasing race conditions is mad: I loath reproducing transient errors. I have mostly tried hard to avoid async code in my own JavaScript, but sometimes it is forced upon me :-(
The outside perception, I am afraid, affects me. I don't want to be stuck all the time doing things that are equally hard, but much less appreciated.
I have a lot of respect for frontend development, and approach it with the same kind of caution and respect that I do the backend stuff, however that is not always appreciated, and since it can get complicated fast, and people are expected to finish quickly as if on a treadmill, those things get messed up, hacked, and brittled up.
Another analysis paralysis issue with frontend is cost/benefit for doing it "right." Since frontend is a leaf and not the dependency of another layer in the application, it becomes dispensible to a certain extend in some scenarios. It is seen as replaceable and not worth spending a lot of time on. So when working on frontend, second guessing whether it will be scrapped off later is always hanging in there, paralysing you between "engineering" mode, or just give it a quick hack.
I would not dread doing frontend development, if allowed to do things correctly.
So now you can be more expressive, target more browsers easily, have greatly simplified script loading and module management, much, much better debugging tools, with less effort.
The tools make it easier for you to be a good developer.
Good web development was never easy.
"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."
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 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?
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();
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...
So are you saying that most projects that use JS should avoid the use of ES6?
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.
State management? What is "a variable"?
Many times the cure is worse than the disease...
Something like htm [1] + ES6 modules is the best of both worlds IMO.
State management? Let React/Vue handle it [2]. No need for Redux/Vuex etc
Need to support IE11? Then yeah, I agree, go back to ES5.
[1] https://www.npmjs.com/package/htm#example [2] https://twitter.com/ryanflorence/status/905584958835638272
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?
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.
When he was born I used to dream of having him look at a button on a web page and him asking me "what actually happens when I click that button"
I shudder to think where I would even begin to answer that today.
https://flems.io/#0=N4IgzgpgNhDGAuEAmIBcIB0ALeBbKIANCAGYCWMY...
nb. You don't need to jump in with any of the frameworks used by companies targeting millions of users. The basics are still there...
The 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.
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 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.
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.
Was it the inflow of too many mediocre graduates that needed help preventing themselves from writing buggy programs? The social credits that people added to their CV for making yet another uber-popular javascript thingy that got a lot of github stars? Or was it bored engineers in the major web companies who have nothing to do because their advertising money cow is already being milked, so they decided to build toys to sabotage everyone else?
> Was it the inflow of too many mediocre graduates that needed help preventing themselves from writing buggy programs?
IMHO? Pretty much. That end result is linked to the desire to democratize programming. That was a common talking point back in the 90s-00's. They wanted normal, non-programming people to be able to make websites by themselves without programmers. They wanted to be more inclusive and make programming more accessible to the masses. They thought one day programming would be taught in schools right next to english and they'd use that skill every day to program their computers themselves. The common phrase used was "programming is the new literacy."
They did not succeed. To make the programming tools and languages easier to use, they had to add complicated abstractions. Objects. Exceptions. Garbage Collection. Types had to go. As a result, programming got a lot easier to make simple things, but a whole hell of a lot more complicated to engineer solid, reliable systems.
A lot of the comments in this very comments section show a great deal of fear at not using a framework to program even a simple website. That's a great example of the kind of mindset we've cultivated over the past 30 years. We're so worried about how to utilize an ever growing pool of barely computer literate junior developers that we've Harrison Bergeron'd our best and brightest.
I recently went to work a two big company, which is considered highly agile and progressive. I was tasked to build a pricing engine to customize prices for a static inventory of products. Number of products were about 30 and did not change month to month. The architecture suggested we use close to 18 different technologies, including caching systems, message bus, reactive programming. All to give 10 possible prices for 30 products. So essentially 300 values and a system to change the rules which determined the prices based on 3/4 parameters. I built the entire system in 2 days which was ready to be tested, but was told to scrap the work as it did not follow the internal development guidelines. Not to mention I was reprimanded for not including team and calling a complex problem trivial as it increased signaling risk internally. Apparently they are still building that system with 5 engineers, 2 analysts, 1 devops person, and 1 team lead. I left the company 2 years ago. And interestingly each and every person on the team got a promotion, multiple performance bonuses in last 2 years.
Also, an application software vendor had A(m,n) problems and thought "What we need is to make the Web into a universal platform capable of supporting any application." Now they, and the world, had A(m+1, n+1) problems.
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.
I meant that, without 3rd-party cookies, tracking is harder. And I'm assuming that users who block scripts also block 3rd-party cookies.
We as a civilization haven't really had a need to reconcile this I think on the scale that we do today. Nothing was "out in the open" so much so as it is today. But now that I can see it somehow my expectation is that I should immediately understand it.
As more and more information becomes available to the masses we all need to start recognizing that just because we can see it doesn't mean we should expect to be able to understand it.
Real knowledge about how to solve complicated problems takes time and discipline to get to the place we want to be individually and collectively.
Given how much I spent doing things this way, I'm quite reluctant to building JavaScript, let alone CSS (though preprocessing first came to CSS, if my mind serves me right). I find the write-test-update loop to be much tighter for frontend work, so I'm quite fond of the old ways of doing things (and all my side projects look the same way as they did back in the early 2000s), but I understand that modern build tools are getting more and more performant. Not as performant as "Save" though :-)
It’s true that you can create a MVVM app feeling with a MVC framework and a little Ajax, but really, I’ve never been more productive than I have with react.
I don’t think it’s really that much more complicated, but I do think 99% of the learning resources are outright terrible, and that was certainly a hurdle I had to overcome. Which is hard, because learning new things while you have a full time job is already hard.
Do you use webpack? Just babel? What about grunt/gulp? How often do these things change? If you left your project for 12 months, would it still work?
It's really not that complicated.
As with desktop programming, you have a variety of build systems to choose from, and as long as you use something reasonably same it is fine.
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 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!
Yes, web development is complicated. Yes, that complexity is at times completely unwarranted. But, that does not mean that the originators of this complexity were simply being stupid. A company like Facebook has a simple requirement: keep users on the site. If that means building a completely overengineered platform or inventing a totally new front end framework, sure, go for it! As long as it keeps the experience so smooth, so seductive that people scroll for hours, absorbing ads and producing money for Facebook.
I wouldn't be surprised if someone did some user testing and the SPA with no jarring refreshes and fluid page changes scored significantly higher on user engagement.
If you look at the companies that have really fancy JS libraries, they're generally places that rely on people using their apps continuously. Netflix? They're practically the poster child for internet addiction. Twitter? Yep. Even old school media companies like the New York Times are starting to use fancy web technologies. Clicks and eyeball time is money. Stuff like React and transpiling and webpack are small prices to pay if they keep your front end developers happy and your website nice and shiny for your average user.
People seem to get openly frustrated if they can't learn overnight all there is to know about a discipline that has taken some people years and maybe even decades to master.
We as a civilization haven't really had a need to reconcile this I think on the scale that we do today. Nothing was "out in the open" so much so as it is today. But now that I can see it somehow my expectation is that I should immediately understand it.
As more and more information becomes available to the masses we all need to start recognizing that just because we can see it doesn't mean we should expect to be able to understand it.
Real knowledge about how to solve complicated problems takes time and discipline to get to the place we want to be individually and collectively.
the web is a mess on the front end for political, rather than computer science, reasons
(say, you don't want to include the 2mb outdated moment.js? well, even though every browser included this code to fetch and update it's IANA timezone database in it's source, and has compiled against it, you can't access it via a public API from JS though LOL... you can figure out a way to run this code to get your data muahahahahahah.... https://www.iana.org/time-zones)
There is a lot to be said for simple, time-proven technology.
[1]: https://medium.com/@mattholt/its-2019-and-i-still-make-websi...
Ironically some of the tools in the article will probably grow old which is part of the difficulty here. People learn the libraries, then it seems a new, better library comes along and makes things even better. Everything comes together once you learn it's about managing the algorithms, data, as well as rendering to the screen.
1. https://www.scientificamerican.com/article/fact-or-fiction-n...
But what I feel quite frustrated about, is the pace at which tools become obsolete. It seems that you can be happy if you have two projects which actually use the same set of tools. And every time you want to fix a bug in some project which you didn't touch for a few months, you run into some kind of trouble while updating the dependencies.
Just today, I spent an hour getting a project to build again, which I built two years ago. I just hope that in the near future the community will settle on a common set of tools which will become stable and stay for a decade or so.
For personal projects, React on Rails (+ Redux) has been a very productive setup. Once you get over the learning hump of how to set up a project it's basically the same thing over and over again.
For my current project I needed a GUI that I initially planned to implement in the browser, but then I started to question this assumption that web development is simpler, and decided to try to refresh my C++ and use Qt instead.
So far it's not a disappointment.
I wrote a bit recently about that here, if you are interested and can bear poor English:
In any given technical environment that has sufficient time to mature there will be more information to process, more choices, and more surface area. It's just the principle of intellectual entropy. Stuff tends to get larger and more complicated and specialized because it is.
If you want something simple, why not invent it? There's nothing stopping the next person from coming along and coming up with something that gets the same job done a lot easier than what we have now.
Of course, the first time you try to implement a tiny portion of a browser primitive like drawing a table you'll quickly see why things are complex.
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.
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.
So now we have meme frameworks and transpilers and hysterical build toolchains all for a platform for sharing documents.
HTML/JavaScript isn't the best way to develop an app, but it's good enough and you can develop very good apps with it.
Yes, because that's valuable to the business. My department makes money doing what we do, I'm making my life easier using an SPA framework.
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.
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 is harder for the simpler tasks that were common 15 years ago. It's harder so the harder (or impossible) tasks of yesterday, today and beyond, are easier for some values of harder and easier related to time and custom coding.
So off they go and try to prove that perception wrong by piling on the complexity.
The problem is this is incredibly valuable and we have no good alternatives. There is simply no better format for deploying applications than the web.
Also winricklabs.com
It's a nice breather after writing AngularJS for six years... I'm sure with the next complicated UI I'll use some big framework (Spring+Leaflet or Angular...)
However, I think the goal should be to reduce complexity and have your business/product be focused as possible.
Watch.ly is literally just live hit counters. The live part gets challenging at some scale. But the product is focused.
Given the choice between learning the business – requiring lots of talking to users to understand what they do and why they do it, and then writing very plain uninteresting code that servers those business users’ needs – or learning whizzy new CV-enhancing technologies and using them to invent excitingly complicated and interesting software problems so they can spend all their time solving those problem instead, which do you think the indolent bums are going to embrace?
Rise of the SPA is great. However, I think unless there is a good reason for having a SPA such as hybrid mobile app development, then there is no point of using SPA.
Normal server side web page rendering with latest modern version of jQueryish/Zapeto should be just fine for the non app type of web development.
* Javascript has evolved from simple requirements e.g. flashy text to a full blown application environment, but there is relatively little base functionality included (e.g. compared to what you get in Java or C#) so people need to write those libs separately.
* The separate libraries above need to be included in your code, and copy/paste is not maintainable so some kind of module system is needed but JS doesn't come with one, so various people rolled their own and they competed for mindshare. 10 different standards.
* As above for UI frameworks. JS only has a basic framework included: the DOM. It's pretty good but doesn't scale "naked" to more complex apps, so again the community creates a whole bunch of those.
* As above for application frameworks (UX frameworks)? such as routers so that you can press the back button.
* Ah the back button - an example of where apps on the web have to care about something that desktop apps don't. There are other examples. Mixing http/https. Mobile responsive.
* CSS - I imagine originally designed for "documents" - now has to work well with "web apps".
* Javascript again - no static typing, many devs find it too easy to make mistakes, we have Typescript and other compile to JS languages.
* Because of the above complexity with have Babel, Browserify, Webpack etc. (one is never enough!)
* Then some genius decides to use JS for the back end and we have Node, NPM, and then because Node is so useful it becomes the front-end tool chain provider. So you use NPM to install Webpack, and the newbie has to figure out difference between dev dependencies and ordinary ones etc.
* git clone https://github.com/... and who knows what stack they've used. Oh they are using Browserify. Never used that. 2 hours reading the docs.
* Each framework then finds ways to get more complex organically. React, Redux etc. and all that.
* Again every other programmer is using 10^10 different combinations of frameworks and techs. Compare to C# Desktop development where it might be they are using Winforms or WPF - that's your only problem!
I could go on. I still copy and paste my favorite templates for getting started with NPM/Webpack/Typescript. Not sure I could demo how to get there from scratch again. All the recommended ones online seem to have beartraps in them and stuff I don't understand.
But remember you all you need is a <script></script>! It's easy!
The current complexity is a result of addressing these issues and doing so at a rapid pace.
- React or Vue?
- Redux or stateful components?
- GraphQL or REST or RPC?
- SSR or SPA?
- ...
We are missing a framework with sensible defaults for all these questions. And that does a good job at explaining what decisions one should take.
I'm trying to build such framework: Reframe (https://github.com/reframejs/reframe).
The software stack is a natural phenomenon that adds to web design's complexity. Ever changing and never complacent, it continues to shape new features that weren't conceivable in the past.
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.
There are other reasons, but that is a huge one.
I found backend development much saner to reason about.
hey what's your timezone? no, i don't mean getTimezoneOffset(); https://www.iana.org/time-zones LOL
You simply cannot be a monolithic craftsman, who wields only a few tools well. Because if you do that, in 10 years you'll be left in the dust complaining about ageism vs knowing new tooling
I'm not advocating this is a good thing, but its the environment we have fostered for ourselves and now we don't like it.
All the tools that are meant to simplify it.
I get that the flash plugin sucked and was a battery hog.
But the development environment was quite decent. I'd love to be able to make HTML5 content in the same kind of way.
My current favorite is the ClojureScript ecosystem, but it's even more different than either still, and really only suited for apps. For a plain old website composed of several pages, mostly static content, it's hard to beat plain old HTML with maybe a light sprinkle of JS for a couple things.
easy
This is a learning process. It isn't something a tool can magically do for you. If you think you can nail this in two hours or by dicking around with some tool you are lying to yourself. Don't worry, everybody with half a brain will see you for exactly what you are, so be honest with yourself that you probably aren't some software rockstar and learn to take the primitive dumb stuff very seriously.
If you are hoping a tool will magically do it for you then you will continue to suck. The web will continue to be a complicated mystery. You will probably continue to cry about how hard life is and people won't want to be around you.
At the most primitive the web is HTTP and HTML. Don't over think this. If you understand those you have the web. You don't even need URI. URI is an added convenience.
Next, build less shitty HTML. Any HTML no matter how ugly, inaccessible, presentation-oriented, user-agent centered, and otherwise broken is still a good start so long as it displays content to a web browser. The first goal of HTML is something that just works... somewhat. Improve on this. Learn to write better HTML and better content. Most people don't take HTML seriously, but this is really the most important part of building a good web experience.
Third, learn some presentation using CSS. This will take some practice. This takes some real practice. It isn't hard, and you can do really almost anything with CSS. Even still people FEAR the CSS.
Fourth, be a damn programmer and stop being afraid to read code. Learn to write JavaScript. Learn the concept of scope. Learn to really read code. A bunch of tooling and test automation isn't going to read the code for you, though many developers seem to think that is exactly what layers of unnecessary tools are for. Keep this very simple at first. Learn some basic events and then bail out. Don't immediately think you are some kind of architectural wizard, because you will fail. If you think a framework will solve this for you then continue to be mystified and confused.
Fifth, learn the DOM. The DOM is the heartbeat, or assembly language, of the client-side application experience of the web. The DOM is what binds HTML to the browser and CSS/JavaScript to HTML. Without the DOM you have a plain text experience with really bad presentation that you shouldn't be using. Frameworks won't teach you this. The best way to learn the DOM, how it really works, is to learn XML Schema. I strongly suggest this even if you never use XML or schemas ever again.
Build on that. Baby steps. It takes some effort but it isn't complicated.
A back end server with this configuration would have a handler layer for IO, business logic layer and data layer.
DI and IoC ensures that the IO layer doesn't know about the data layer as the logic layer takes it as a dependency. The IO layer consumes the logic layer and the logic layer doesn't care/know about that.
Front end is exactly like this. The data source is REST rather than a database. The UI layer is an event source and consumer. The logic layer notifies its consumers (the UI layer) that there has been a change. The rendering library doesn't matter, it's just a mechanism to represent the events it consumes.
The problem in front end is there has been no rational mechanism for DI in the libraries. React relied on the service locator pattern to deliver dependencies so to ensure quality decoupling you would need to have wrapped your components with a million functions.
``` withTheme(withUsers(withSomethingElse(withAnotherThing(Component)) ```
So rather than that, just use a single "service", redux, and forget about DI. Everything can do anything and all your logic is done inside that one thing.
Angular is no better. While they have a nice DI solution, it still relies on concrete implementations rather than abstractions. So your business logic must live within "angular services" and can not simply be "javascript" consumed by a rendering library.
Vue just missed the point entirely.
React context packaged this problem in an ergonomic box and, in my opinion, is a fantastic solution given the constraints. However at this point, the meta in front end programming is so irrational that it boggles my mind.
In the following example, you can see that I have an application which uses React as a renderer. React consumes a package from /platform. The package has no relationship to the presentational layer.
I could run the units in the package inside node or the browser console and it wouldn't care about its rendering library. The "PostStore" class exposes an API which consists of a getter and a stream. React consumes the stream, because it needs to be notified on changes.
https://stackblitz.com/edit/react-ts-biohay?file=gui%2Fapp.t...
Conversely, this loose coupling means that the view renderer is a small portion of the application. I could swap it out for another renderer. Preact, Svelte, whatever.
Front end is a mess.
If there was a way to quantify a good design vs a bad design through an algorithm then people can iterate in ways that properly and categorically makes things better rather than in ways that are opinionated, vague and possibly even in the wrong direction.
Modern web development is not about making things more efficient or easier to do.
It is about proving you have a job title or knowledge that makes you more hire-able, raise-worthy, title-superior than Junior Devs.
Web dev is actually easy if you want it to be, avoid the hype and use simple tools that work out of the box.
It's not just web development that is hard. You can't honestly say any toolchain on the desktop side is any easier.
That said, web development is getting easier now that the dust is settling and only a few major frameworks are used.
Get started with create-react-app. React is the industry standard, use it.
1) Install NodeJS
2) npx create-react-app demo
Packaging these without depending on preinstalled software is hard (you probably shouldn’t even bother trying on Linux, everyone there expects installing weird stuff to involve using either git or a container anyway.)
As far as I can tell the main reason people don’t use it is that it can’t make iPhone apps.
additionally, if your app has any design/layout issues, now you need to hire for people that can do visual layout using tcl/tk.
If your app consumes rich text, you're in for a real treat as you are now on the hook for figuring out how to manage that as well (in addition to serialization, you also need it to likely be emitted into some web friendly format anyway. if your app consumes some feed (say new-user facing features or whatever), you need to find some meta-format that your app can use to layout that content (or i mean, i guess you can use a webview, but then...)
if your customers are enterprise-ey, you are now dealing with some overzealous IT dept that is skeptical of your application running with user permissions.
if you're trying to push a fix/update to your users, you now need to build infra around deploying new apps as well as customer support determining if users are somehow running old versions when they report a bug.
the web is a total "mo money, mo problems" situation, but i think people dismiss how many problems the web solves for your developers on a day to day basis: easy to push updates, simple to whitelist your app's domain on some restricted network, easy add dynamic content/layout to portions of your app with stored content, (less sync resolution issues because your app probably requires network to operate) etc. Native apps have their own issues, they're great, don't get me wrong, but people demand a lot from basic apps of any stripe these days, and as those requirements increase, so does the amount of complexity that developers need to manage at all stages of the pipeline.
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.
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)
Why, yes. Yes, I can. Delphi, for example. Visual Basic. Frankly, I think Cocoa and Gtk+ are easier.
2) npx create-react-app demo
How many steps does it take to start from scratch with other toolchains?
2) django-admin startproject mysite
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.
Not really a sensible comparison. The tooling to build desktop interfaces remains vastly, vastly better than the tools to build web interfaces.
Other than SwiftUI I'm not sure what rivals React when it comes to the design.
And all these years I thought that HTML was the industry standard...
> Because we're no longer making websites, we're making apps
This is exactly right. Some projects should be SPAs, some SSR, some just a little HTML and jQuery. Use the right tools for the job.