The answer to "why is ___ so ___?", is very nearly always best when phrased as the question, "what was supposed to stop __ from __?" The answer is nearly always...nothing.
There was nothing, technologically or organizationally, preventing web development from becoming so complicated, such that websites whose desired functionality would be satisfied by static html are now several meg of thousands of lines of javascript on top of a few dozen included libraries. There was nothing preventing that. Therefore, it happened.
Developers don't really feel like pointing out, "you should get rid of me and just pay for someone to do html".
Managers don't really feel like pointing out "the project I'm managing doesn't really deserve a team of developers, you should take them away from me."
The designers don't feel like pointing out "all we really need is to put this well-formatted text on a page with the company logo on the top and one or two image files, and that will communicate the information just fine, you can get rid of me."
The even-higher-ups don't really feel like pointing out "I don't need to hire all these people, you can take this VC money and return it to the original investors".
The VC's don't feel like pointing out, "there's not really a use for this much money in the tech world right now, so you can just stick it in a bank account and wait for a real need."
So, it doesn't happen, because there was nothing to prevent it.
> There was nothing anymore preventing web development from becoming so complicated
The early web was much simpler because of the resource constraints of the 90s and early 2000s. Pages only started serving 10 MB of JS when browsers got to the point where they could chew through 10 MB of JS at a barely acceptable pace.
Also:
> Managers don't really feel like pointing out "the project I'm managing doesn't really deserve a team of developers, you should take them away from me."
As a techie watching corporate politics from the sideline, this was a particularly depressing insight. I used to wonder why big companies require 50 employees to do the work that small companies need 10 employees for. I do not wonder anymore.
Resources are allocated to their constraints. You spend as much money as you have, as much time as you have, you hire as many people as you can afford, and so on.
It may be because people don't think on an absolute time scale but rather a relative one; if you make 1 million in revenue and you only have 3 employees, you might feel like you should hire more. What happens if you start making one billion in revenue?
Read Bullshit Jobs by David Graeber if you haven't already.
In the early 2000s I worked for a company whose IT infrastructure was primarily Microsoft based. Maybe about 10% of the company had Macs, and we typically had to fight to get them. The Windows boxes required a huge amount of IT support per capita, while the Macs pretty much just worked and the Mac users didn't need much help. Not to mention that the Windows boxes were notoriously malware-prone and needed constant patches and the Macs didn't. I wondered for a long time why the company didn't just switch entirely to Macs. After all, most of the corporate apps were web-based and they worked fine on either platform. It took me a while to figure out exactly what you wrote above: The CIO didn't want a small, lean organization. He wanted a huge organization with a huge budget, because that's what looks good to C-level executives. Hence, Windows was the officially-sanctioned desktop solution.
I love your comment, but I think it does miss out on some important concepts.
I used to think when I first started my company that I could just do every part of it far better than anyone else. I would push on my employees pretty hard and often denigrate their efforts. As the company is continued to grow, I now have 180 full-time employees. The reason I have all these people is that they can do enormously more work than I can and most of them are now better at doing their individual job than I am.
I think your comment visits are tendency as tech people to view ourselves in the best possible light, and to view other people as not as good. We especially tend to view projects we do as big and very complex and project done by others as not impressive.
The other thing is, programmers love re-inventing things. Its the standard programmer mindset of wanting to work on problems that are one or two levels of difficulty over their currently capability. And so, they fuck shit up, because only someone whose been in the weeds, knows the ins, outs and the corner cases, is capable actually doing a good job. (IMHO, $0.02, YMMV etc)
I'm not sure if I fully agree with your point about developers or managers not wanting to suggest they aren't needed. You're argument relies on the idea that most business needs could be sufficiently met by static html doesn't really fit how businesses works. If a business in an industry has additional functionality on their page that gives them an edge beyond just text on a page, then it is needed. Additionally, when extra functionality is needed the whole industry is going to compete on that. Most businesses don't have enough extra funds to support unnecessary or non-competitive functionality development, so while there might be something better they could be doing with their money, it's almost never the case that what's being developed is so over complicated or over architected that it would be a better financial move to build a static page or site than what they're doing because losing that competitive edge often results in the company, division or product line failing to get enough sales to continue.
You do make something of a good point about nothing preventing web development becoming over complicated, except you seem to have forgotten how much that costs. Unless there is a perceived marketable difference, people will rarely push for it to be developed at all, and given the size of the average development team's backlog that pressure to develop also has to outweigh everything in the backlog as well.
The honest truth is that web development has become so complicated because that's the equilibrium point of the supply of labor to the demand for advanced features. Developing the same features from scratch using static web development methods takes exponentially longer as a function of feature complexity, and the ability to use frameworks and other more complicated tools reduces that down to being merely linear.
Web development isn't complicated because nothing is stopping it from being complicated, it's complicated because consumers want features that they assume should be simple, but are in fact very complicated.
While this is occasionally true, I believe it is most of the time not true. Many, many features (e.g. endless scrolling) get pushed out to consumers who don't want it. By and large, consumers of websites want text and images. The push to put embedded video, lots of ajaxy updating of content, etc. has happened on countless newspaper, magazine, and other websites where all the consumer wants is the words and the images. Many features, like allowing comments, are actively disliked by the vast majority of users. There are, certainly, a few corners of the web that need more than static html, but >90% of the websites in existence that are _not_ static html, should be, and the consumers would like them better that way.
This seems demonstrably untrue. Basic html development is vastly cheaper than “modern JavaScript” which would give any company w an HTML-only strategy a huge advantage. Why aren’t HTML-only companies dominating in every market?
Because it had to play catch up to native apps feature wise due to demand, while building upon a base that wasn't intended for that, while serving the same app to literally thousands of different environments and expecting it to work perfectly.
Thus, growing pains and overly complicated frameworks/plugins/other bits slapped together to address the core issues which ballooned the complexity. But we all knew that.
What's more impressive is that things are getting less complicated. Browser monoculture, while bad for the freedom of the web, is going to simplify things radically. Only having to target rolling releases for Firefox and Webkit? That's a dream from a cross-plat support side. Also javascript is actually pretty good now. Webcomponents once Chrome 77 drops and Firefox matches parity will finally be production worthy, and they're actually quite easy to build. I've been making static sites with them recently and it feels so much cleaner than going with a React or other component library approach that uses a vdom. The HTML is readable again, and there isn't any needed compilation step or crazy npm dependencies.
While it will never be as easy as it was back in the mosaic days, web dev is simplifying.
"What's more impressive is that things are getting less complicated."
Over what timeframe? While it certainly had its own issues, the HTML5/jQuery pairing easily fit into your head. Notwithstanding the benefits, React, packers, routers, and the 10 other things you bundle, is a cognitive load. Doesn't help that the routers and 10 other things don't come with React, and so, choices vary across teams.
There are many JS libraries that are wonderfully simple. I think the problem is:
- Too much choice; it's insane how much you have to decide before you get started: React or Vue? SSR or SPA? REST, GraphQL, or RPC? PostCSS or Sass? CSS-in-JS? What router? Redux or stateful components? Axios or Fetch API? Client-side rendering/routing or server-side rendering/routing? Webpack, Parcel, Create-react-app, Next.js, or Gastby? And the list goes on... I mean that's just nuts.
- State management is inherently complicated; people don't realize that 90% of the case you don't need interactive / stateful views to build a product. People implement bunch of useless interactive "niceness" that are overkill because React allows them to. If you use React as an HTML template engine then React is actually super simple and super neat.
How awesome would it be to have a framework that has sensible defaults for all these questions. And that educates how to decide certain crucial aspects.
For example:
- Use plain old HTML instead of interactive views if you can.
- Don't start with Redux. Instead, use Redux only after you know exactly why you need Redux.
I'm not sure comparison is correct. If you want routing in jQuery app - you will have some similar concept to routers. Using packers is also not required. And if you want some good automating module splitting in jQuery app - you'll probably pick up some packer as well. So it's more like HTML5/jQuery can be compared to just React without additions.
Most of these things that bring cognitive load have some purpose. It looks from time to time that developers start making tools in the sake of tools, but most of the time there's some sane reasoning behind.
Form registration for webcomponents is coming. Personally when trying to create a component system it's been the number one blocker I've had. Your work arounds were not great - either you'd have to mirror an input in the lightdom (not good if you're using a library that strictly enforces a vdom), or you have to use a forked form component (not good as few people will know to use it and will wonder why the x-input isn't sending its data to the form).
Once form registration is in place you'll be able to create component libraries that should truly work no matter the environment or libraries being used alongside them (as long as you have an up to date browser).
It doesn't have to be complicated, if you get support from above.
A few weeks ago I launched a new web site for a health care company. HTML, PHP, CSS, and MySQL. No frameworks. No javascript. No garbage.
It replaced a site that was a mess of javascript libraries on top of frameworks on top of a half dozen jquery version and on and on and on.
The company administrators, doctors, practitioners, etc... are so happy with the new no-nonsense site that they raved to the parent company about it. The parent company's IT department looked into the site, asked me some questions about it, and yesterday I was been asked to do the same type of cruft-free rebuild of three other sites that the company owns.
Not buying into the framework-of-the-day hype just landed me job security for the next two years.
Did you consider that the next developer might well come along and post a similar comment:
> It replaced a site that was pretty much a home-grown PHP framework written by a single developer. Random mixed logic in templates, hard to update CSS and a poorly designed 'not-an-ORM' ORM.
Not to say that your rewrite is like that, but one man's garbage is another man's treasure.
I'm sure it's possible. Someone may come along who is all into DrupalPress and Agilereactboxqueryhack and think it's primitive.
But they won't be able to say it's not maintainable, upgradable, or scalable. And it's documented out the wazoo, all the way down to the CSS both in code and in the accompanying PDFs. The last developer gave zero thought to who would come next. I've given great thought, and included the occasional quotation in the code comments from Goethe where appropriate.
But if the company wants to pay him/her to blow away my work, then that's neither my business, nor my problem.
And here's the trick to not building shit software: don't build shit software. It's a crude way to put it, but the reality is that you can build bad websites in any framework (including old PHP stuff and new JavaScript hype). You can also build good websites in any framework.
It depends way more on the organisation or team developing it than on the libraries you use.
was just about to comment along these lines! i never understood those eschewing frameworks... in the above example a PHP framework like Laravel is in constant development by lots of people, with security updates and refinements pushed out on a regular basis. even if u are an uber-developer, in what situation is rolling your own ever the right choice? is your project that different from everyone else's?
> but one man's garbage is another man's treasure.
Not entirely related, but there is usually the incentive to at least say this for a new person/team coming on because money. Especially for frontends, the new person/team we talk to when going into an existing project, says that it has to be redone because it's 'not up to standards'. That is not because it's not fine and maybe even beautiful; it makes more money to rewrite it. And job security perhaps too. So when someone says something is garbage, I need to assess the reason why; is it garbage or does the person saying it benefit from a rewrite somehow.
Logic in the templates... are you describing PHP or React?
To be fair the parent comment isn’t saying everything about his stack is perfectly elegant, but if you can deliver a website that works without stateful client side JS and associated build tooling, then it certainly is simpler, and most of the time simpler is better.
As long as the code isn't abstracted more han 1 or two layers deep, it's commented in places where the control flow isn't that intuitive, and follows best practices for whatever the kids of languages is, it doesn't matter if it's home spun. Just being "home grown" is not synonymous with bad software. At the end of the day, just using frameworks are no guarantee that the code is readable and maintainable. Usually by the time someone is looking at your code to rewrite or update it, what seemed like an awesome choice of framework at the time can end up being a nightmare to parse as documentation has dried up, forums that were the sole source of knowledge are offline, and now your once amazing code is just garbage to the poor coder trying to make sense of the random abstractions of the framework.
Did you consider that up to a certain point any framework, be it home grown or commonly used, makes things more complicated?
Simple cgi endpoints and static files for any css/js should be our starting point and any web developer should understand them. When the problem becomes bigger and more complex is when we should start looking at frameworks.
Not necessarily. If the new developer rewrites in a modern framework again but the user experience becomes terrible (looking at you modern reddit), then the new developer cannot really say that. As a developer, I understand the hard to update CSS etc but that is far better if the user experience remains great.
When was the last time you had a go at CSS? So much has changed since 2017. You can chuck out the pre-processor junk and just use CSS variables and CSS Grid. Productivity is 10x.
You can even keep it simple so that a page just loads the CSS it needs instead of some 40,000 line ball of junk.
Same with templates, if you are using CSS Grid you don't need the sea of div containers, you can just use actual content elements from HTML5 and never use a div.
Pseudo-selectors mean you don't need spans. You can get pretty things done without the markup in the document. Once you write HTML this way you wonder what on earth people are doing with these impossible toolchain and impossible HTML web pages. Regular development from about five years ago with frameworks and jQuery nonsense just looks like hacks.
The true judge is the user experience, not the code quality. Modern web sites try to be apps, with tons of whizzy nonsense that breaks on user browsers, to the users' detriment, when they should be simple CRUD sites to manage digital files.
Right, but will they be able to say that the customer was thrilled with their rewrite? Probably not; they're already mostly happy with the simpler site and now they've paid to make things (almost certainly) more complex than they need to be. They probably feel swindled into agreeing to a rewrite of something that was mostly working but The Next Developer told them that adding that new feature would require completely rewriting the front- and backends.
I am reminded of the Picasso story where he meets a woman in a park and makes a 30 second sketch. The woman asks how much it would cost to buy it and he replies something like $1000 (insert large amount of money for 30 seconds of work). She asks him why so much money for 30 seconds of work and he replies that it took him 30 years to draw that sketch.
It's easy to build a simple website with no frills that does exactly what the client needs -- if you know how to do it. Even then, it is rarely easy to figure out what the client needs!
A colleague wanted to use a Javascript library for something I thought was probably pretty simple. I suggested we take a look at the library and see what it was doing and determine if it was worth the extra dependency. He joked, "If I wanted to know how it worked, I wouldn't have chosen a dependency". Luckily, it's not how my colleague really feels, but this is exactly what's happening most of the time.
Things are over complicated because people don't know how to build them -- they glue together a patchwork of stuff so that they don't have to know. In the end, they tend to build something whose complexity is many orders of magnitude higher than the complexity of the problem they are working on.
Your two years of job security was not for avoiding framework-of-the-day hype: it was for knowing how to do it. It's the simple 30 second, single line sketch that captures the picture perfectly with no extra complexity. That takes years and years of experience to develop -- and a desire to even get there at all.
I take a similar approach for 9/10 of the enterprise web apps I build, but use ASP.NET Core MVC instead of PHP, and I also favour SASS.
Point is that SSR (Server-Side Rendering), with a sprinkling of simple JavaScript and XHR calls as required, is enough for almost everything I do, and it means build are really simple. Doubly so with a strongly typed language like C#.
I've worked on Angular and Vue projects, and the complexity level was (subjectively) much higher, despite these particular web apps not requiring any real level of client-side functionality. I find JS tests to be much more complex and brittle than C# ones too. Honestly, I hated it! Now, some of this was undoubtedly because I'm more comfortable with what I know, but certainly not all of it.
People vastly underestimate how complex client side code can get and how much automatic functionality browsers hand you. Whereas a nice web framework has users, permissions, session management, templating, validations and forms all set up for you with battle tested out of the box behaviors.
A frontend framework is great if you are a company that really needs to slim down bandwidth and can hire expensive devs to maintain it. But for a simple no nonsense business application it’ll just slow you down and will gravitate towards being a mess.
Damn, you broke into my top-secret consulting role ;)
I completely agree with all of this. There is probably a billion-dollar market out there for rewriting garbage business apps that were developed using the hipster tech flavor of the week.
The market may be large, but that seems like saying the market for cooks is large. The work required for doing 4 sites is double the work required for doing 2. Unless theres some scaling secret I dont know about.
I wonder what your brand new greenfield project is going to look like in five years when it's been passed through the hands of a few interns and contractors and survived a couple different ownership shuffles.
Think it will look as maintainable as it is today?
Or do you think a new consultant will roll through and easily sell the client on another rewrite-from-scratch project?
Framework-dependent projects tend to go stale and become "ew I don't wanna touch that, it's so last year, we should probably replace it with [newer version of framework that's gonna end up being much harder to upgrade than expected / other framework]" surprisingly fast once eyes are off them, in my experience. Without someone competent doing continual upkeep, the next guy/gal's gonna try to sell the re-write anyway. May not succeed, but they'll try. Framework or no.
Recognizing the right tool for the job landed you job security for the next two years (and you're deserve it!)
But it could have very easily gone the other way. If your website had complicated validation rules on multi-page forms (not unheard of in healthcare) the site would be better off for some basic state management interacting with a standardized authentication/authorization framework that you didn't have to write.
From what you're describing, it sounds like you did right by the client in this circumstance. But sometimes, it does have to be complicated. And in those circumstances, frameworks and javascript (unlike garbage) have an important place.
For one-dev sized projects (i.e. simple crud type apps) this may well work.
However I would be concerned about a couple of things if this were me and I was doing anything beyond the absolute most basic web app:
- long term maintenance. Doing something only you understand and only you can maintain (that job security you mention) is a bit of an unprofessional dick move IMO.
- if you need to get other people in to help, you now have to spend more time training then up on your custom system that they don't understand and keep an eye on them to make sure they are doing it right and not introducing security issues
- When your client wants to integrate with some common third party thing ("hey can we put Google maps in here?"/"we need to integrate with stripe payments") you'll need to reinvent the wheel from scratch to do it using your custom system rather than just use a well-supported off the shelf library.
- you'll need to stay 100% up to date on all security issues/approaches/classes of vulnerability to make sure your custom system is secure. Your audit was ok this time, but everytime you make a change to your custom library (e.g. to support Google maps or stripe) you're now going to need to go through the audits again to be sure you've not opened up any new security holes (and perhaps new ones you've not ever heard of because you are only working in this weird little custom system/thiefdom for the past 2 years)
- how to support the INEVITABLE requests for extra features that require something client-side that cannot be easily done with only PHP and static pages. It is not the 90s any more - the cat is out of the bag regarding interactivity ... the requests for client-side nicities that users are used to in other things WILL COME! Clients always want more! :-)
Still anyway I guess you don't need my good luck wishes as I am sure you are correct and that you really have out-thought and out-coded all of the well-supported and well-funded frameworks that have been built by many thousands of people and have been battle-tested in the field for years (e.g. Laravel, .net MVC, struts etc). Because otherwise if you hadn't totally out-smarted the entire industry, I'd be shitting myself and checking my professional liability insurance about now.
I think people are assuming he wrote a pile of hot PHP garbage, but it's entirely possible he just wrote it using Symfony or Drupal and well understood PHP libs and just has no 'modern javascript' to do it, which if he did would cover all of your points. If you haven't gone back to current gen PHP in a while there are some quite solid models that are very maintainable, have security updates (via composer) and so on. It's entirely possible that he didn't do a crazy thing but we'll never know.
A decently structured PHP application is often maintained by nontechnical people with a limited understanding of programming but they can get by with just a text editor and a codebase. I have not come across any nontechnical person who could easily get a react/modern js framework pipeline going to do a small change, not to mention dealing with npm changes. I would almost feel like it would be a jerk move to leave someone without a technical department a pile of react/npm soup right now.
There's nothing in his post suggesting that the way he developed is harder for someone else to pick it up. MVC Frameworks aren't necessarily easier to use than vanilla PHP. Your answer reminds me of people who don't know how to use vanilla JavaScript and have to add jQuery to the project for things that could be one-liners in vanilla JS.
The whole "what if the customer needs something in the future" is just a piss-poor excuse that bad developers make to prematurely optimize. There's nothing in an MVC framework that makes it easier to add new features.
There is nothing preventing him from using official libraries for Stripe or Google Maps if needed.
There is nothing preventing him from using libraries that can be updated, probably with a single CLI command.
There is nothing suggesting his system is unsafe. Quite the contrary.
He didn't outsmart the entire industry. He just built something that works without relying on your favorite tool. Maybe you should try someday, you might actually learn something.
A simple php endpoint is something any web developer can understand. The more frameworks/libraries/patterns/abstractions you throw in the less likely it is they will understand it. Especially years later when the framework is inevitably out of date, good luck convincing why they need to spend money upgrading a framework every year.
> hey can we put Google maps in here?
Has this changed recently? Last I checked you would just drop a script tag into the page, who needs a library for that? Edit - I checked (https://developers.google.com/maps/documentation/embed/guide), how does a framework make a copy/paste job any simpler?
> "we need to integrate with stripe payments"
I'm not familiar with stripe, but don't you just give it a return url? I don't see how a framework would help at all here.
> you'll need to stay 100% up to date on all security issues/approaches/classes of vulnerability to make sure your custom system is secure.
This is harder with a framework, it's one more thing to keep updated. The less libraries the less vulnerabilities.
> Doing something only you understand and only you can maintain
Having worked with both kinds of application, I personally find it much easier to learn my way around and understand a self-contained application than one which is a giant web of moving-target third party dependencies and frameworks, themselves largely undocumented and subject to the framework-hipster "move fast and break your users' things" mentality.
My background is mainly frontend, but I'm well versed in backend as well. I've been actively advocating at my company to stop with this whole separate frontend and backend, and instead just return plain HTML and some basic JavaScript when needed.
In most of my personal projects I've been following this approach too, and I must say, I'm so much more productive. I don't find myself constantly switching between browser-, terminal and VS Code-windows. I don't have to do validation twice anymore, and know perfectly where all my data is coming from.
I built a SPA and found making the API and linking everything up to be needless overhead. The way I find works best is using rails templates to simply insert a div with all the data needed in the attributes and then having react render everything.
I once worked on a team of about 30 people building a website for a university that could have been a team of one dev and one designer and a static site generator.
This seems odd to me. I have been working in .Net MVC/Core and while I could write an application that is simply HTML/CSS/C#, I would think it would be insane to do so.
It takes a massive amount of resources to develop your own security, your own data access without any ORM tools, not cause memory leaks, properly disposing of resource.
I'm all about creating reliable applications, but a good framework is a great tool.
Questions for PHP, and MySQL folks (not meant in a negative way):
- PHP: A few years ago I heard about how PHP was needlessly complex. I wonder what the recent status of the programming language is. Specifically, do experienced PHP programmers stick to a subset of PHP, as in "PHP: The good parts"? (similar to "Javascript: The good parts"). (side note: As a diehard python person frustrated due to latest versions becoming bloated in features, I fully acknowledge that I'm in the "Python: The good parts" camp right now).
- MySQL is owned by a company lately. I wonder if PostgresQL is clearly a better alternative?
Modern PHP development comes in the form of loading dependencies from Composer/Packagist, rather than offloading a lot of bloat to the language. Lots of things have been deprecated (and even removed, like ext/mcrypt).
I think the discussion point was php was too easy and that encouraged new developers or less hardcore developers to adopt it.
Some of the defaults like globals being turned on by default led to security holes. How people were creating sql statements at the time concating strings led to sql injection issues.
There were never any bad parts . There are new features like the spread operator that are newer and not available in earlier versions. I try to stay away from them if I think the application will need to run on older versions but otherwise I feel like I can use any feature.
Postgres needs to run under a specific os user. That alone makes it a poor MySQL replacement
I don't think you're being fair. I certanly agree that a lot of things that should be simple are over-engineered simply for the sake of it, but there are a lot of things that are made possible by modern frameworks.
I'm really not trying to plug our thing now, but if you look at this [1], a short tech demo of the platform we're building, there's no way it could have been built without modern frameworks with the amount of people we're building this
There certainly are some types of apps that are mind-bogglingly complex (e.g. press play and scroll around on https://kepler.gl/demo/nyctrips for one vivid example) but ironically, the real heavy lifting is mostly done with specialized libraries and super-close-to-the-metal code (GSLS), whereas the "modern" stack only powers the "simple" boxy UI glue stuff.
Not that I disagree with your approach technically, but if I did that, I would have felt like I wasted my time. No job is secure and you did hardly any Resume Driven Development.
Also, if I were a team lead, I definitely wouldn’t have chosen that stack because it’s harder to recruit career driven developers who don’t want to work on tech that doesn’t help then build their resume.
When it’s time to land the next job, using $cool_kids_stack of the day, you will be at a disadvantage.
For context, when it comes to modern front end development, I’m barely above “not eat the chalk” level of competence so this is definitely not meant as a technical critique.
> The company administrators, doctors, practitioners, etc... are so happy with the new no-nonsense site that they raved to the parent company about it.
Any reason they liked it in particular? Faster? Better/cleaner UI?
What tech you use is much less important than the way you use it. If you build great stuff that works well your clients will be happy, and they'll give you more work. It's not complicated.
Very similar thing is happening for me as well, only for a large property management company.
Their old sites were weighed down with an incredible amount of confusing technology.
I redid the whole thing with PHP/HTML/CSS/JS/MySQL as well, and it's incredibly easy for them to update and work with now. Super simple admin interface, attractive front-end, and the top brass at the company has taken notice.
Yeah everyone assumes you have to build out an SPA and then you need a rest or graphql service behind that. It rapidly gets out of hand for the benefit of having a native like experience you wind up serving sites with 1 gig of us framework content per page.
The point of using a good framework is that conventions and best practices are enforced. If your building a Rails sits there are a set of conventions everyone follows. When a new developer onboards onto the project they know how to extend the code base.
I have a similar story. I got hired on to replace some PHP web apps, each one written using a different framework. Each one out of date, unpatched, unknown dependencies, no easy way to bring up to date-- tied to specific old PHP versions. A big mess. The IT director was pretty savvy and said he wanted a clean rewrite without frameworks, something I was all too happy to do.
This is my problem at the moment. I have a nice static site, but I'm facing demands from the marketing team to use Wordpress so that they can make copy changes to the site without having to go through a developer (or learn any HTML).
"Modern-looking" these days means shitty JS that tries to be a "WebApp" and breaks basic website conventions like open in a new tab middle click, and uses the same GUI both for small touchscreen and large desktop, so ends up working poorly on both. Why would anyone want that ?
I used to code in ASP and PHP back in the day, and that approach made a lot of sense. You'd have things that run on the server, and then those things throw out a website for the user to interact.
If there's a need for reactivity, use some JS, but basically it all goes back to the same server program.
I always found that this approach was good enough. You could do a lot, heck, I even wrote a browser game back in the day. Most importantly, it was simple, and it led to great web pages that would always work and could be used as such. No JS, no cookies? No issue, your code would just deal with it. A button was a button, and link was a link, and your browser did the rest. Text got sent as html, pictures were loaded or not depending on your preferences. Everything got faster and faster. This was years ago.
In the meantime, I stopped doing web dev.
Suddenly, in the last ten years or so, I noticed that websites became bad. The whole web just seemed to regress. Everything was JS, everything became single page, and if you didn't enable every single function in your browser, or if you pressed the "back" button, or reloaded the page - basically if you did not pretend that the website's UI was an actual native program - then everything breaks. News sites stopped loading text or images halfway through, buttons stopped working. Links were not clickable. Pictures would not show up. LOADING bars and circle-things appeared on websites that were already downloaded on my computer. Registration forms did not load default options, choice elements were empty. Once the page was loaded, everything was sloooooow. Scrolling became "different" and often laggy. Websites would load, then do something in the background to reload into garbled messes. Printing didn't work correctly. It's like Flash websites of my day (that everyone know were terrible and had very few good use cases) became the norm, but without Flash.
What happened to the internet? Why is everything garbage? Did all web developers die out?
I went back to make a simple website for myself. Reading tutorials, it was clear I had to use some framework. It was recommended to use JS, install some sort of server application and database, then a framework on top of that, and then something that runs in the user's browser. But everything was its own programming language, with no common denominator. You'd either need a PhD in JS and server development, or be happy to buy in to some framework that was usually not even very good.
I did not understand anymore how web development works. I did no longer understand how the websites came to my customer, what the server did, how and when it did it... and everything was hard, even though this should all be really simple. And what came out was just... bad.
I went back to using simple web dev tools if I need to, and thought "well my needs are just not so advanced". But given that most websites have become so terrible, I just can't help but feel it all went wrong.
Whoever thought up this frameworks and JS revolution was probably really smart, and there are probably some really good websites out there.
But I hate the internet now, and I don't understand web development anymore.
I'm not even that old.
Hopefully, considering just how shitty things have become, this will just be a fad that will quickly die out... especially once devs start to catch up on JS advances of the last 4 years?
This sounds like you wrote something extremely limited. The client will inevitably ask for some modification to it, and if you're not there to do it the next developer is going to curse at you for writing such a brain dead application.
I've seen comments like this on HN and then I've seen these types of applications in the wild. I call it the most dishonest form of consulting you can do. You've put a real shine on some inflexible shit and the clients obviously have no way of knowing what they've bought into.
>It replaced a site that was a mess of javascript libraries on top of frameworks on top of a half dozen jquery version and on and on and on.
These people are incapable of correctly evaluating work they contract out, or who is doing it. Why do you think you're an exception in this case?
I've seen countless unmaintainable applications written using popular MVC frameworks that required simple modifications, but the next person in line wasn't able to understand what the hell was going on.
Popular frameworks are not silver bullets, but apparently it's popular on HN to think so.
I can assure you "owning" a home-baked software is 10 times harder than anything that is popular.
Thats from someone who does that for a living.
Modern web-devs move faster than they think, leaving so many doors open. Someone who works on the same system plenty of years had time to patch the doors.
I agree that there are much better choices, but most frontend apps are done with onion oriented development with thousands of dependencies that constantly get vulnerabilities, and aren't any more maintainable in my experience.
If it's simple enough and they understand PHP well, it could easily be better.
Eh, not using popular frameworks is a recipe for unmaintainable sites. You're missing a lot of features these provide for free.
Accessibility
Cross browser polyfills
Easy translation support
Automatic mobile view
Developer mindshare
The lack of polyfills is VERY concerning. Your site probably doesn't work on 10% of browsers. And getting from 90-99% is an excercise in futility.
If you used a popular UI framework and transpilation you could easily write a super modern site that works on practically everything back to IE6. And with Vue or React the whole thing could be a few hundred KB, probably smaller than some of your images.
If I was brought in to work on your site, I would immediately rewrite it if it's more than a few pages. Plain HTML with PHP becomes an unmaintainable rats nest if you try to do anything complicated.
Honestly I think it's kind of worrying that this opinion is so popular. Aren't you essentially saying that frameworks are in most cases useless, and "job security" is something you should strive after?
First of all, "job security" means that you're irreplaceable, and in the case of you actually being the architect/designer, that probably means you did a (perhaps intentionally) bad job to make yourself the linchpin. Not good.
Secondly, regardless of the first point, programming is hard. Anyone that says otherwise should be avoided like the plague. It's beyond the scope of one individual to be able to keep up to date to all the security issues and gotchas prevalent in a language or ecosystem. This is why you use frameworks. They're democratic units that within themselves handle patches and development in ways that are often better than one "irreplaceable" developer on a unique object (of course, bad developers can still use frameworks and derail the product completely to the point where all benefits of the framework are negated, but that's beside the point).
Because, Webpages have become complicated. Suddenly, you have all this interactivity going on, which you didn't have a decade ago. We went from a series of simple hyperlinked inter-connected webpages to all these popups shoving onto our face, useless fake computer bots pretending to be tech-support and finally big co. tracking every single click, every pixel of your mouse movement. The web has come a long way to support all these.
One of my clients was an airline. He asked if we could track the usage stats of his in-flight entertainment system (just stats, no PII). I thought about it and said yes. Even I was amazed I said because a decade ago it wouldn't be possible. I got it done with service workers (because flight wi-fi isn't a 100% always on connection).
It was a boon for me because I made a lot of money on that project and I needed the money. It's also a curse because every browser has all these invisible code running behind the scenes whether you want it to or not.
I miss those days where everything was just a bunch of tables and default system font-powered webpages with plain blue links. No CSS, no popups, just html and pure content.
> I miss those days where everything was just a bunch of tables and default system font-powered webpages with plain blue links. No CSS, no popups, just html and pure content.
You mean like HN? You 're not missing it. The old web never left. It's still here to catch all the misguided cloud walkers when they fall.
Webdev isn't complicated. Its actually pretty simple. Because its simple, you can use the extra time you saved to solve complicated problems. Which then brings it back up. When the platform makes THOSE problems simple, you just move on to solve other more complicated problems.
Basically, developers can support complexity <x>. No matter what you do to simplify it, you'll always push toward <x>, just getting more value out in the process. If you don't, your competitors will.
Also, even the most complex rollup/webpack/react/redux/styled-component/npm/blah/blah/blah setup has nothing on the kubernetes/kafka/databases/queues/whatever infrastructures of the world.
It just turns out that while your little pet project that cuts every corners to get something working has little on software development that requires everything to line up, be fast, reliable, comply with all the laws and regulations, and scale once your company grows and you suddenly have hundreds or thousands of people that need to work on the same stuff.
One thing to add: some people actually like setting stuff and optimizing infrastructure, build processes, setup, and pushing it to its limits. So development stacks quickly get optimized for a very common way to staff organizations: have a team that handles all the setup and infra, and a bunch of teams that build on top. So when you try to have 1 person or 1 team do everything, it feels like too much.
Webdevs tend to suffer from an inferiority complex, that they are not considered “real” developers by the rest of the community. So they have responded by making the simple things they do monstrously complicated to try to prove something to the C++ guys, who simply don’t care, until they try to use the dumpster fire that is any modern website, that is. Then it has the opposite of the intended effect!
Someone else mentioned SPAs. I 100% guarantee that no user in the world ever wished for their “back” button not to work as they expected.
Calling themselves “full stack engineers” is another symptom of this.
I might have agreed the inferiority complex existed in the early 2000s, but I don't see it anymore. Rather I think the negative thoughts go the other way, maybe not inferiority from non-webdevs, but jealousy. You can find n00bs who graduated a coding bootcamp and are now making a significantly larger amount of money doing webdev stuff than a bunch of middle aged guys working on legacy native applications who studied the arcane C++ arts and had to get a BS degree to even get an interview.
I'm playing contrarian here a bit, so excuse the unqualified language. It seems these days anyone who isn't a webdev in some capacity* is probably a dinosaur, inflexible, less well-paid, lacks understanding of complex distributed systems, and in any case is irrelevant in the modern conversations around development. Might makes right, after all, there are vastly more webdevs than non-webdevs and the most valuable software companies make their money from distributed systems interfaced with via web browsers... The notable exception is probably the group of native mobile application developers, but that's only become more and more webdev-like since both the iPhone and Android took over, rather than the reverse.
* Even being back-end only for a back-end whose only front-end is web-based. Yeah I am conflating webdev beyond the post's qualified "front-end developer". But the back-end webdev guys get up to the same overly complicated architecture-astronaut crap we like to complain about the front-end webdev guys getting up to. Don't let me go off on J2EE/JavaEE/Spring.
I'm not sure you understand the amount of embedded software that runs the world -- or at least think about it appropriately.
And the amount of system and infra software that is needed to even let the web exist.
An "application" is not just a cute GUI that a consumer or an office worker can interact with. Nor is the interface the most complicated parts in some systems. I found your projection and generalization as ridiculous as if you said: even the EE needs to master the web technology, and they are not very valuable if they don't.
Hey, they are web devs of various levels. It is ok to be one, especially a good one. It is also ok to be, I don't know, a compiler expert, a kernel hacker, a baseband FW engineer?
The thing is: you often forget about what works pretty much correctly and silently, even when you use it all-day long... :P
> Webdevs tend to suffer from an inferiority complex
Well, that sure is an arrogant way to present stereotypes as fact. At first, I read this as satire.
You can follow the history of web development and see exactly why the current stack is as it is. It's people building solutions to problems.
For example, nobody thought "I should create a front-end build process to impress my peers!". What happened instead is that repetitive tasks were programmed out of existence.
The web industry is young, you can trace every single steps of it without much research. To claim something as ridiculous as "responded by making the simple things they do monstrously complicated to try to prove something to the C++ guys" is silly at best.
Sure, this may be accurate for some of the junior devs. you worked with in your career. However, this is not representative of the industry as a whole.
You can follow the history of web development and see exactly why the current stack is as it is
I have lived this history of web development. I remember when CGI was new and exciting. Now I see modern sites using literally thousands of times the memory and CPU to struggle to do things that were trivial even back in the 90s on a 486 with 8Mb RAM.
A typical document, say a news story might be 2kb-5kb in size. Why does the page need 5Mb of JS to deliver and display it?
So I am 100% confident in my assertion that the web as it is today is massively and needlessly over complicated.
It most definitely doesn't seem so. People build multiple solutions to nonexistent problems, or problems that are only relevant to google (which classifies them as nonexistent problems for everyone else). Then they push those solutions where they don't fit (e.g. SPAs for blogs)
I consider people getting real work done, without caring what anyone else thinks of their chosen tech, even in Excel VBA to be just as “real” as anyone.
Backend dev here. I tried to create a simple Angular app. I got into some kind of dependency hell on something simple. Going from Angular 7 to 8 broke some junk? Then trying to get Angular Bootstrap to work was hellish as well, especially when some kind of polyfills junk screwed up for IE.
Ended up just linking to it directly to the jquery and bootstrap CDN...
It's been a long time since I did any kind of major front end work. I think it will stay that way. I don't do enough work with it long enough to really "get it" and retain it.
sorry you felt that way.unfortunately you dealt with the shit-show that is Angular + TypeScript, which is not beginner friendly AT ALL. I would ask you try using create-react-app, https://facebook.github.io/create-react-app/, and drop jQuery. JS is really awesome now and everything that was "in" jQuery can be achieved through standard library.
Well, choosing the right tool for the job is part of being any kind of developer. If you could solve the problem with no framework/lib/state manager, why go that way? The fact that those tools exist doesn't mean you _have_ to use them.
> they are not considered “real” developers by the rest of the community
Well, a lot of them aren’t - until recently, a lot of front-end developers were actually graphic artists who were more skilled in photoshop than software development (not to knock that skill, it’s a useful one!). It doesn’t help that 23-year-old MBA “unicorn startup” founders have bought into this pipe dream model of software development where a couple of eggheads in the unlit server room develop algorithms that the $10/hour mcweb-developers cut-and-paste into beautiful templates.
Well I'm not primarily a web developer, but I've worked alongside many. This neither describes any of them, nor would it be tolerated (or even possible to pull off) in any workpace I've seen. Self-puffery is admittedly endemic to contemporary tech/con-preneurism, but this is a quite ludicrous 'explanation' of a complex reality.
Masterfully condescending. I also appreciate the dig at JS via C++, which is perhaps the most complex programming language still widely used in the industry.
> If you lack a fundamental understanding what people are building obviously it seems overcomplicated.
Hi. I have a fundamental understanding of what people are building. Most of it's overcomplicated and the "web app or not?" decision's very often made due to hype, résumé padding, or making a project look more impressive to other internal folks. Some of it's justifiable as a "webapp" is truly a decent choice but still usually performs worse than is reasonable, indicating overcomplication under the hood—look at various Google "webapp"s performance dropping steadily over the years as features remain similar or drop off, and that's not even comparing them to older non-webapp incarnations which are universally much snappier (though usually missing some features, to be fair).
sorry, but if a front end interface is not easily understood, it is bad. its entire purpose is to have usability attributes, like predictability. SPAs break back buttons , new tab buttons, scrolling positions etc, the most basic stuff of web navigation
Funny thing: in the last couple years I've seen way more back buttons broken because of backend idiossincrasias than anything else.
It is super common to see "Don't use your back button" messages after placing orders on e-commerce websites.
On the other hand, most frontend developers writing SPAs just use react-router or something like that (instead of reinventing the wheel) and it just works.
Yet there was a post about how specifically to do that on dev.to because their users couldn't tell their modal was a modal, and the solution they came up with was to hijack the back button.
The person who is writing their own game engine and doing everything from the ground up. They haven't shipped anything yet. They're five years into this with a few more to go.
> I think this is it more than anything. People wanted to make the web complicated because it made them feel cooler developing it.
That is patently false. What happened is product managers wanted their websites to feel cooler to their customers, and work more like native apps. Developers then respond to the requests from the product managers. For example, charts that refresh data without a page reload when you click a button. The requirements get more and more complex, and the web was never meant to be an application platform. So you end up with what we have today.
This comment (and so many others on this thread) demonstrates such a complete lack of understanding of web development and SPAs.
Knowing as little as you do about SPAs, why do you think you would be able to understand all the intricacies of the problems they solve. Don't claim that people
> make the web complicated because it made them feel cooler developing it
just because you don't understand the issues.
It would be like me claiming that pro golfers wear golf shoes "just to look cool", when in reality, golf shoes probably offer some advantage that I'm just not aware of.
that sounds absurd to be true, even though it is also absurd how monstrous the javascript train has grown. And come on, C++ is not that complicated, i think ppl used assembly when they wanted to be obscurantists
It's complicated because the bar in terms of user experience went up (or so they say) and now everyone wants a SPA. Because of this you now have a generation of devs that only knows how to build SPA. I'm actually thinking to move some stuff from Django to Gatsby/React setup just because everyone knows React, and a lot of our new devs don't know Django/Python.
"Everyone wants a SPA" is such bullshit. GitHub used to just load for a hundred milliseconds and then show me everything I needed; now it loads for a hundred milliseconds and shows me a spinner while it does another roundtrip for some javascript, then parses and executes that giant truckload of code, then does _another_ roundtrip to get the JSON or whatever describing the data I actually want to see, then executes its boatload of javascript to update the DOM. Reddit is the exact same story; in the time it used to take to show the content, it now manages to load a spinner. Facebook also just spends the first few hundred milliseconds loading loading indicators. YouTube too.
Browsers are awesome at rendering HTML. They render each element the instant just the necessary bytes have crossed the wire. Browsers can't help you if you need to first load the HTML, then load the scripts, then load the complete giant JSON blob from your API, then add the elements to the DOM.
I'm in Norway, with high ping to the US. My ISP isn't the most reliable all the time. That nice server you have 0.01ms ping to, where you can't notice the difference a few extra roundtrips makes? Well, each roundtrip might take an extra few seconds for me.
The worst example I can think of right now is: GMAIL..
God it went downhill lately. It can take 20 seconds on a decent machine for it to load all the shitty plugins i dont even need but still block me from using a mailbox..
Loading "html only" version is pretty much instant and has everything I need to use the demn mailbox..
I think we’ve done a great job of convincing each other within our tech bubble than everyone wants a SPA. Not sure the general public cares for our enthusiasm though.
This, this, this. Users didn’t ask for magazine websites - which should be serving up, y’know, images and text - to sit and spin on my phone while all the Javascript libraries load. Users didn’t ask for these things; we as a community just decided to foist it on them.
Everyone(well almost) wants a SPA or at the very least non reloading pages. No one wants to reload the page with every action they perform or if only a part of the area on screen needed to be updated and the page was reloaded anyways.
SPAs don't need to be complicated, people have been developing native GUIs for decades. The source of the problem is the browser event and rendering loop which remains a mystery.
Yes, exactly. But to me in many ways that's application programming on the Web vs. Web programming. It may seem pedantic but it's two separate skill sets, and my teams that do each are separate (I have front-end devs that are basically application programmers using Angular/React and front-end devs who are CSS/JavaScript/Animation specialists -- they aren't the same teams).
This comment makes me realize, I need to get back to my RoR roots and build a server side rendered site again to see what I've forgotten with building React sites for a while.
I'm not blaming the tools, but too often, at least (for me) based on multiple interactions with various devs/engineers - yes, sometimes on Twitter :) - tools are proudly spoken of as a proxy for quality product. That is, I'm using the latest wiz-bam shiny new object tool so the users of the product must be overjoyed.
Nah. Nobody cares. I think that bears repeating...Nobody cares.
My mum has __never__ said to me "I love React" or "Isn't Bootstrap the best." But she __has__ complained to me about a site/app being buggy, confusing, difficult, etc. I've said the same to myself too many times to count. I think we all have.
A couple months ago, I read an article about (frontend) tools and how important X, Y and/or Z are. The author's product had a repo on GH. There were 700+ issues. All I could think was, "Apparently those tools have given his team a false sense of security. Looks like they've bitten over more than they can chew." I filed the article under: Just because you can, doesn't mean you should.
Years ago, I remember reading an answer on Quora (when Quora still mattered) that included:
"A fool with a tool is still a fool."
I don't think I'll even forget that line. It's so true. I'm not against tools. I'm just not in favor of those who claim tool X, Y or Z is a panacea.
You see that everywhere. In my field unless a dedicated statistican was a coauthor, chances are they picked the wrong test to use for significance. And if you look through their past papers you might find that they only use that one test that they always run, despite whether or not its relevant for their data.
In any field you can find people putting blind trust in tooling without knowing how the tool works or what its even intended for.
A solid idea well executed will beat a great idea poorly executed.
Sure, we all love to learn new things and/or push the envelope. That's what side projects are for. But when such things come at the expense of "the product" with a real user base than something as gone wrong.
"I love dealing with fast-moving things that are broken," said no user ever.
Readit News
There was nothing, technologically or organizationally, preventing web development from becoming so complicated, such that websites whose desired functionality would be satisfied by static html are now several meg of thousands of lines of javascript on top of a few dozen included libraries. There was nothing preventing that. Therefore, it happened.
Developers don't really feel like pointing out, "you should get rid of me and just pay for someone to do html". Managers don't really feel like pointing out "the project I'm managing doesn't really deserve a team of developers, you should take them away from me." The designers don't feel like pointing out "all we really need is to put this well-formatted text on a page with the company logo on the top and one or two image files, and that will communicate the information just fine, you can get rid of me." The even-higher-ups don't really feel like pointing out "I don't need to hire all these people, you can take this VC money and return it to the original investors". The VC's don't feel like pointing out, "there's not really a use for this much money in the tech world right now, so you can just stick it in a bank account and wait for a real need."
So, it doesn't happen, because there was nothing to prevent it.
> There was nothing anymore preventing web development from becoming so complicated
The early web was much simpler because of the resource constraints of the 90s and early 2000s. Pages only started serving 10 MB of JS when browsers got to the point where they could chew through 10 MB of JS at a barely acceptable pace.
Also:
> Managers don't really feel like pointing out "the project I'm managing doesn't really deserve a team of developers, you should take them away from me."
As a techie watching corporate politics from the sideline, this was a particularly depressing insight. I used to wonder why big companies require 50 employees to do the work that small companies need 10 employees for. I do not wonder anymore.
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.
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.
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...
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.
Deleted Comment
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.
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.
- 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
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.
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).
Deleted Comment
Deleted Comment
A few weeks ago I launched a new web site for a health care company. HTML, PHP, CSS, and MySQL. No frameworks. No javascript. No garbage.
It replaced a site that was a mess of javascript libraries on top of frameworks on top of a half dozen jquery version and on and on and on.
The company administrators, doctors, practitioners, etc... are so happy with the new no-nonsense site that they raved to the parent company about it. The parent company's IT department looked into the site, asked me some questions about it, and yesterday I was been asked to do the same type of cruft-free rebuild of three other sites that the company owns.
Not buying into the framework-of-the-day hype just landed me job security for the next two years.
> It replaced a site that was pretty much a home-grown PHP framework written by a single developer. Random mixed logic in templates, hard to update CSS and a poorly designed 'not-an-ORM' ORM.
Not to say that your rewrite is like that, but one man's garbage is another man's treasure.
But they won't be able to say it's not maintainable, upgradable, or scalable. And it's documented out the wazoo, all the way down to the CSS both in code and in the accompanying PDFs. The last developer gave zero thought to who would come next. I've given great thought, and included the occasional quotation in the code comments from Goethe where appropriate.
But if the company wants to pay him/her to blow away my work, then that's neither my business, nor my problem.
It depends way more on the organisation or team developing it than on the libraries you use.
"After me cometh a Builder. Tell him I too have known."
http://www.kiplingsociety.co.uk/poems_palace.htm
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.
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.
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.
Deleted Comment
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.
Deleted Comment
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.
I completely agree with all of this. There is probably a billion-dollar market out there for rewriting garbage business apps that were developed using the hipster tech flavor of the week.
I’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.
Deleted Comment
Think it will look as maintainable as it is today?
Or do you think a new consultant will roll through and easily sell the client on another rewrite-from-scratch project?
But it could have very easily gone the other way. If your website had complicated validation rules on multi-page forms (not unheard of in healthcare) the site would be better off for some basic state management interacting with a standardized authentication/authorization framework that you didn't have to write.
From what you're describing, it sounds like you did right by the client in this circumstance. But sometimes, it does have to be complicated. And in those circumstances, frameworks and javascript (unlike garbage) have an important place.
It almost never has to be complicated. People just enjoy making it so.
Looks at their inventory management system
jQuery would fit well here.
However I would be concerned about a couple of things if this were me and I was doing anything beyond the absolute most basic web app:
- long term maintenance. Doing something only you understand and only you can maintain (that job security you mention) is a bit of an unprofessional dick move IMO.
- if you need to get other people in to help, you now have to spend more time training then up on your custom system that they don't understand and keep an eye on them to make sure they are doing it right and not introducing security issues
- When your client wants to integrate with some common third party thing ("hey can we put Google maps in here?"/"we need to integrate with stripe payments") you'll need to reinvent the wheel from scratch to do it using your custom system rather than just use a well-supported off the shelf library.
- you'll need to stay 100% up to date on all security issues/approaches/classes of vulnerability to make sure your custom system is secure. Your audit was ok this time, but everytime you make a change to your custom library (e.g. to support Google maps or stripe) you're now going to need to go through the audits again to be sure you've not opened up any new security holes (and perhaps new ones you've not ever heard of because you are only working in this weird little custom system/thiefdom for the past 2 years)
- how to support the INEVITABLE requests for extra features that require something client-side that cannot be easily done with only PHP and static pages. It is not the 90s any more - the cat is out of the bag regarding interactivity ... the requests for client-side nicities that users are used to in other things WILL COME! Clients always want more! :-)
Still anyway I guess you don't need my good luck wishes as I am sure you are correct and that you really have out-thought and out-coded all of the well-supported and well-funded frameworks that have been built by many thousands of people and have been battle-tested in the field for years (e.g. Laravel, .net MVC, struts etc). Because otherwise if you hadn't totally out-smarted the entire industry, I'd be shitting myself and checking my professional liability insurance about now.
A decently structured PHP application is often maintained by nontechnical people with a limited understanding of programming but they can get by with just a text editor and a codebase. I have not come across any nontechnical person who could easily get a react/modern js framework pipeline going to do a small change, not to mention dealing with npm changes. I would almost feel like it would be a jerk move to leave someone without a technical department a pile of react/npm soup right now.
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.
Agreed in general, but there are better free/libre choices. I don't recommend these for greenfield projects.
In most of my personal projects I've been following this approach too, and I must say, I'm so much more productive. I don't find myself constantly switching between browser-, terminal and VS Code-windows. I don't have to do validation twice anymore, and know perfectly where all my data is coming from.
MVC PHP frameworks are very nice and they don't move as fast as those javascript frontend rendering.
Also the ORM deals with any security problems and most framework deals with other security deals too including session handling.
It takes a massive amount of resources to develop your own security, your own data access without any ORM tools, not cause memory leaks, properly disposing of resource.
I'm all about creating reliable applications, but a good framework is a great tool.
I think it's way nicer. I much prefer environments like Sinatra, Express or Flask than full-blown MVC frameworks.
- PHP: A few years ago I heard about how PHP was needlessly complex. I wonder what the recent status of the programming language is. Specifically, do experienced PHP programmers stick to a subset of PHP, as in "PHP: The good parts"? (similar to "Javascript: The good parts"). (side note: As a diehard python person frustrated due to latest versions becoming bloated in features, I fully acknowledge that I'm in the "Python: The good parts" camp right now).
- MySQL is owned by a company lately. I wonder if PostgresQL is clearly a better alternative?
See: https://phptherightway.com
Modern PHP development comes in the form of loading dependencies from Composer/Packagist, rather than offloading a lot of bloat to the language. Lots of things have been deprecated (and even removed, like ext/mcrypt).
Some of the defaults like globals being turned on by default led to security holes. How people were creating sql statements at the time concating strings led to sql injection issues.
There were never any bad parts . There are new features like the spread operator that are newer and not available in earlier versions. I try to stay away from them if I think the application will need to run on older versions but otherwise I feel like I can use any feature.
Postgres needs to run under a specific os user. That alone makes it a poor MySQL replacement
It has different philosophy, and needs a little getting used to, so it's not as easy as simply lift-and-shift
[1] https://www.youtube.com/watch?v=SkjMUY_cAmw
There certainly are some types of apps that are mind-bogglingly complex (e.g. press play and scroll around on https://kepler.gl/demo/nyctrips for one vivid example) but ironically, the real heavy lifting is mostly done with specialized libraries and super-close-to-the-metal code (GSLS), whereas the "modern" stack only powers the "simple" boxy UI glue stuff.
Also, if I were a team lead, I definitely wouldn’t have chosen that stack because it’s harder to recruit career driven developers who don’t want to work on tech that doesn’t help then build their resume.
When it’s time to land the next job, using $cool_kids_stack of the day, you will be at a disadvantage.
For context, when it comes to modern front end development, I’m barely above “not eat the chalk” level of competence so this is definitely not meant as a technical critique.
Any reason they liked it in particular? Faster? Better/cleaner UI?
Their old sites were weighed down with an incredible amount of confusing technology.
I redid the whole thing with PHP/HTML/CSS/JS/MySQL as well, and it's incredibly easy for them to update and work with now. Super simple admin interface, attractive front-end, and the top brass at the company has taken notice.
This is my problem at the moment. I have a nice static site, but I'm facing demands from the marketing team to use Wordpress so that they can make copy changes to the site without having to go through a developer (or learn any HTML).
I'm not sure why you need a modern "looking" site since JS is about the functionality not the looks.
The funniest comment I have read on this website.
Wait, PHP is not garbage?
I used to code in ASP and PHP back in the day, and that approach made a lot of sense. You'd have things that run on the server, and then those things throw out a website for the user to interact. If there's a need for reactivity, use some JS, but basically it all goes back to the same server program. I always found that this approach was good enough. You could do a lot, heck, I even wrote a browser game back in the day. Most importantly, it was simple, and it led to great web pages that would always work and could be used as such. No JS, no cookies? No issue, your code would just deal with it. A button was a button, and link was a link, and your browser did the rest. Text got sent as html, pictures were loaded or not depending on your preferences. Everything got faster and faster. This was years ago.
In the meantime, I stopped doing web dev.
Suddenly, in the last ten years or so, I noticed that websites became bad. The whole web just seemed to regress. Everything was JS, everything became single page, and if you didn't enable every single function in your browser, or if you pressed the "back" button, or reloaded the page - basically if you did not pretend that the website's UI was an actual native program - then everything breaks. News sites stopped loading text or images halfway through, buttons stopped working. Links were not clickable. Pictures would not show up. LOADING bars and circle-things appeared on websites that were already downloaded on my computer. Registration forms did not load default options, choice elements were empty. Once the page was loaded, everything was sloooooow. Scrolling became "different" and often laggy. Websites would load, then do something in the background to reload into garbled messes. Printing didn't work correctly. It's like Flash websites of my day (that everyone know were terrible and had very few good use cases) became the norm, but without Flash.
What happened to the internet? Why is everything garbage? Did all web developers die out?
I went back to make a simple website for myself. Reading tutorials, it was clear I had to use some framework. It was recommended to use JS, install some sort of server application and database, then a framework on top of that, and then something that runs in the user's browser. But everything was its own programming language, with no common denominator. You'd either need a PhD in JS and server development, or be happy to buy in to some framework that was usually not even very good. I did not understand anymore how web development works. I did no longer understand how the websites came to my customer, what the server did, how and when it did it... and everything was hard, even though this should all be really simple. And what came out was just... bad.
I went back to using simple web dev tools if I need to, and thought "well my needs are just not so advanced". But given that most websites have become so terrible, I just can't help but feel it all went wrong. Whoever thought up this frameworks and JS revolution was probably really smart, and there are probably some really good websites out there.
But I hate the internet now, and I don't understand web development anymore. I'm not even that old.
I'm really glad to see that this no nonsense approach catches on.
Dead Comment
I've seen comments like this on HN and then I've seen these types of applications in the wild. I call it the most dishonest form of consulting you can do. You've put a real shine on some inflexible shit and the clients obviously have no way of knowing what they've bought into.
>It replaced a site that was a mess of javascript libraries on top of frameworks on top of a half dozen jquery version and on and on and on.
These people are incapable of correctly evaluating work they contract out, or who is doing it. Why do you think you're an exception in this case?
If I'm the next developer I would thank him.
Ever deal with 5 versions of jQuery that are conflicting. Trust me life is easier in vanilla php.
Popular frameworks are not silver bullets, but apparently it's popular on HN to think so.
Also I'm 97% sure I could own your site in under a day, based on how home-baked you just said it is, and I'm garbage at pen testing.
Healthcare site, you say? Jesus Christ, I hope they have data breach insurance.
Thats from someone who does that for a living.
Modern web-devs move faster than they think, leaving so many doors open. Someone who works on the same system plenty of years had time to patch the doors.
The internal and external security audits already performed by the billion-dollar healthcare company in question disagree with you.
If it's simple enough and they understand PHP well, it could easily be better.
Accessibility Cross browser polyfills Easy translation support Automatic mobile view Developer mindshare
The lack of polyfills is VERY concerning. Your site probably doesn't work on 10% of browsers. And getting from 90-99% is an excercise in futility.
If you used a popular UI framework and transpilation you could easily write a super modern site that works on practically everything back to IE6. And with Vue or React the whole thing could be a few hundred KB, probably smaller than some of your images.
If I was brought in to work on your site, I would immediately rewrite it if it's more than a few pages. Plain HTML with PHP becomes an unmaintainable rats nest if you try to do anything complicated.
First of all, "job security" means that you're irreplaceable, and in the case of you actually being the architect/designer, that probably means you did a (perhaps intentionally) bad job to make yourself the linchpin. Not good.
Secondly, regardless of the first point, programming is hard. Anyone that says otherwise should be avoided like the plague. It's beyond the scope of one individual to be able to keep up to date to all the security issues and gotchas prevalent in a language or ecosystem. This is why you use frameworks. They're democratic units that within themselves handle patches and development in ways that are often better than one "irreplaceable" developer on a unique object (of course, bad developers can still use frameworks and derail the product completely to the point where all benefits of the framework are negated, but that's beside the point).
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.
Deleted Comment
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.
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.
I have lived this history of web development. I remember when CGI was new and exciting. Now I see modern sites using literally thousands of times the memory and CPU to struggle to do things that were trivial even back in the 90s on a 486 with 8Mb RAM.
A typical document, say a news story might be 2kb-5kb in size. Why does the page need 5Mb of JS to deliver and display it?
So I am 100% confident in my assertion that the web as it is today is massively and needlessly over complicated.
It 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 mean, you only need check out all the vulnerabilities in said C++ software for verification of that fact :)
I think what you're trying to say is that you don't consider 'webdevs' to be "real" developers.
Ended up just linking to it directly to the jquery and bootstrap CDN...
It's been a long time since I did any kind of major front end work. I think it will stay that way. I don't do enough work with it long enough to really "get it" and retain it.
Pahahahahahaha. There is no group in our industry with a bigger chip on their collective shoulder than "C++ guys".
Well, a lot of them aren’t - until recently, a lot of front-end developers were actually graphic artists who were more skilled in photoshop than software development (not to knock that skill, it’s a useful one!). It doesn’t help that 23-year-old MBA “unicorn startup” founders have bought into this pipe dream model of software development where a couple of eggheads in the unlit server room develop algorithms that the $10/hour mcweb-developers cut-and-paste into beautiful templates.
This is funny because C++ used to be considered a shining example of this. Software is a flat circle.
This opinion invalidates the rest of your post. If you lack a fundamental understanding what people are building obviously it seems overcomplicated.
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).
It is super common to see "Don't use your back button" messages after placing orders on e-commerce websites.
On the other hand, most frontend developers writing SPAs just use react-router or something like that (instead of reinventing the wheel) and it just works.
Yet there was a post about how specifically to do that on dev.to because their users couldn't tell their modal was a modal, and the solution they came up with was to hijack the back button.
Some SPAs are cool. Easyeda.com is pretty cool.
But also: storing information about a page in the URL is pretty cool too. It makes it possible to link to the page, for instance!
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.
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.
I think people who don’t understand the web talk it down to make themselves feel superior.
Deleted Comment
Browsers are awesome at rendering HTML. They render each element the instant just the necessary bytes have crossed the wire. Browsers can't help you if you need to first load the HTML, then load the scripts, then load the complete giant JSON blob from your API, then add the elements to the DOM.
I'm in Norway, with high ping to the US. My ISP isn't the most reliable all the time. That nice server you have 0.01ms ping to, where you can't notice the difference a few extra roundtrips makes? Well, each roundtrip might take an extra few seconds for me.
God it went downhill lately. It can take 20 seconds on a decent machine for it to load all the shitty plugins i dont even need but still block me from using a mailbox..
Loading "html only" version is pretty much instant and has everything I need to use the demn mailbox..
In fact, I'm pretty sure Github is rendered server side for the first load. You shouldn't be seeing any spinners. I'd check if I wasn't on my phone.
It's not that difficult if you're a decent programmer, and if they're not then why hire them?
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.