There is a difference between web design and web application development. If you are a designer making brochure sites for small business, you don't need the modern frameworks and toolkits, and you are over-engineering it if you use them.
Everyone needs to take a step back and ask why they are building a web site in the first place. My local hair salon really just needs a brochure, and maybe a scheduling widget. A doctors office would need to add on a payment system. Both of which can be achieved by pulling in a script to use a 3rd party solution, while the core web site can remain plain, static HTML... done in Notepad, if you want to get really simple.
When you step up to needing some actual functionality, there still is a line in the sand where a few PHP scripts will do the job, and can just be pushed up to a shared web host.
When you cross that line, THEN you need modern tools. And many sites will need to go there. But a boutique design firm should be able to go a long way without, and probably could just hire some devs if they do land a project large and complex enough to need that level of code.
Just because you can go complex doesn't mean you should.
>There is a difference between web design and web application development.
His essay isn't really about documents vs apps.
It's about documents vs documents. Or more accurately,
he's lamenting about docs_simplesyntax vs docs_complicatedsyntax.
He shows an example of easy HTML syntax[1] that harkens back to "simpler times" in the olden days:
<html>
<head>
<title>My First Web Page</title>
</head>
<body>
My First Web Page
</body>
</html>
The problem with that is people want to author documents (not apps) that are more complicated (prettier, aesthetically pleasing column layouts, gradient backgrounds, drop caps, dynamic resizing of frames, and so on) that require more knowledge than his "hello world" type of simple HTML.
Even a web "document" like the wikipedia page on The Beatles[2] requires quite a bit of complexity and advanced HTML knowledge. I've been writing HTML on and off for 20 years and I'd have to do quite a bit of googling and stackoverflow research to replicate that wikipedia page.
I agreed with you until you mentioned that the problem stemmed from people want[ing] to author documents (not apps) that are more complicated..., thus implying that to make "pretty, fancy" web pages you need to complicate the process of creation: I totally disagree with that premise and think that it's entirely possible to create complex looking and behaving web pages without complex code or processes.
However, for the sake of convenience (mostly), people have accepted the use of 15 different toolkits as the normal prerequisite to creating websites. Why add a one liner JS script in the head when you can npm install it, etc...
Writing html and css like the old days is just as possible today as it was back then, and you now even have better tools to do so (Html 5, CSS 3). It's just a matter of actively choosing to do so.
For the Web pages for my startup, I just started with what I wanted the pages to look like. Then I calculated where everything should be. I looked at this as a special case of layout in word processing, e.g., D. Knuth's TeX.
Then I turned to HTML and saw tables. Okay, the HTML table constructs are nice, sorry D., nicer than in TeX. So, I decided to use tables.
I heard about CSS, but I saw only a little need for that. Eventually I wrote a few lines of CSS. So, sure, I discovered that I could have separate CSS files, but that seemed like a way to slow the upload to the users. So, I just copied the CSS into the HTML code of the relevant Web pages.
For the rest, I saw how to use the Microsoft .NET ASP.NET to create and send the pages with the appropriate dynamic content, e.g., the results for the user.
I heard about JavaScript but saw no big need for it and so far have written not even a single line of it. Eventually I discovered that somehow ASP.NET writes a little JavaScript for me, maybe having something to do with cursor positioning -- maybe convenient and nice but not really necessary.
For the page designs, they are simple -- high contrast, large fonts, simple parts and pieces easy to understand right away, each page exactly 800 pixels wide, no icons, pull-downs, pop-ups, roll-overs, or overlays. There are some links, but each one is just a word in English.
The pages all have both horizontal and vertical scroll bars and should still be usable in a window only 300 pixels wide. So, the pages, without change, should look good on everything from a smartphone to a high end desktop. The user just needs a Web browser up to date as of maybe 10 years ago -- so, there should be no compatiblity problems. And, there are no user IDs, passwords, logins, or use of cookies! JavaScript is optional!
There really are some really simple, really successful Web pages on the Internet. So, sometimes simple can be good enough!!!
>, thus implying that to make "pretty, fancy" web pages you need to complicate the process of creation: [...], people have accepted the use of 15 different toolkits
I wasn't implying that nor endorsing the use of toolkits to complicate process of creation. Yes, the vast majority of other comments in this thread have focused on overuse of "tools" and "frameworks" but my point was about his first frustration mentioned... the syntax itself becomes more complex to achieve richer (non app) web documents. Yes, the author mentioned "npm" and "react" but his first paragraphs were the exasperation of syntax TABLE "<TD><TR>" to CSS float.
Staying with that theme, his subsequent paragraph emphasized the increase complexity of syntactic foundations before accounting for any toolkits and HTML generators:
>My point is that the foundations are now sufficiently complicated enough on their own that it seems foolish to go add more optional complexity on top of it. I’ve kept my examples to the most basic of web implementations, and I haven’t touched on Javascript, animation, libraries, frameworks, pre-processors, package managers, automation, testing, or deployment. Whew.
My point (which is based on the universal phenomenon of increasing complexity in other document layouts languages such LaTeX, Postscript language, etc,) is that the small and simple HTML example he cited isn't full-featured enough for modern web documents. I learned to code "plain HTML" by hand in 1990s but my beginner's knowledge of a few HTML tags in my brain isn't enough to replicate a Wikipedia page. If I decided to do it, it wouldn't matter if I used Dreamweaver, or used a Javascript static site generator, or typed HTML5+CSS3 by hand in Notepad ... the end result would still be a more complicated set of illegible syntax that continues the exasperation of <TABLE> to CSS flex float.
For example, one desirable feature of a modern document (not app) layout would by dynamic resizing of page components depending on big desktop vs tiny smartphone screen. Every example out there to accomplish that (whether multi CSS files, or single CSS file dynamically changed by Javascript) will look more complicated than his "hello world" HTML. For any new feature "X", there's a minimum Kolmogorov complexity to accomplish it which makes the syntax grow in complexity.
I lost count of the number of web projects I had to work on that could be rewritten in a tenth of the code, for more performance, better maintainability and less entanglement between components.
Both on the server side and on the client side. Its really, REALLY easy to build complex software; but that never scales or evolves well over time. You end up saving on initial development only to be constantly plagued with problems in the future.
There is a difference between web design and web application development. If you are a designer making brochure sites for small business, you don't need the modern frameworks and toolkits, and you are over-engineering it if you use them.
This is true, but the fundamental argument Frank makes in this article is just as applicable to web applications, if not more so.
We are now building significant software that happens to be written in JavaScript and to run in a browser. We call the results web applications, but it’s still just software. The basic principles of building software well are still the same: using modular design to decompose a large system into more manageable parts, separation of concerns, choosing the right data structures and algorithms, being systematic about covering different cases... These are all as relevant to developing front-end web applications as any other non-trivial software.
None of those things implies a need for overcomplicated tooling. None of those things implies a need for dependency trees with an unmanageable level of complexity. None of these things requires a combination of trial-and-error coding and rapid deployment. You can build large, complex, robust, useful web applications perfectly well without those things.
Usually, good tools are simple and do one job well. The tools that have stood the test of time in my web programming toolbox — things like jQuery, Lodash, SASS, Babel, Browserify, Mocha and React — almost invariably fall into that category. I find much less benefit in tools that require more than a few seconds to set up, depend on anything not obviously related, introduce any non-trivial boilerplate that I’m not almost always going to need, or introduce any sort of non-standard changes to source files that aren’t all but guaranteed to work in the long term.
Of course there are no absolute rules here, but it has been my experience that heavyweight frameworks, scaffolding generators, build process and the like often trade off short-term convenience against stability and longevity (and often, worse, understanding what is really happening). Like the current emphasis on continuous/rapid everything, that isn’t necessarily a good trade to make if you’re interested in building larger, more complicated, longer-lived software, as we increasingly are in front-end web development.
I agree with your overall sentiment. That said, a doctor's office is a bad example. A modern one probably needs:
1) A brochure.
2) Scheduling.
3) A messaging system (sending email with health info is
not HIPAA-compliant, obviously).
4) A way to look up lab results and whatnot.
5) On the back end, a way for the doctor to
_enter_ the lab results.
6) Ideally a way to automatically generate and print out
kids' vaccination information forms for schools.
and probably other things I'm not thinking of. 1-5 are common; I haven't run into #6 yet, but I keep hoping. Now you're correct that the right answer is to outsource all this, not least because of the HIPAA compliance problems.
For small local business, a Facebook page can serve the purpose of a business website quite well. It provides convenient means to contact the business (via messenger or listed phone number) and from what i know costs nothing to setup and maintain.
> When you step up to needing some actual functionality,
I would say that, given that the hairdresser’s and doctor’s sites do what they were designed to do, they also have actual functionality. Perhaps “fairly complex” would be more descriptive?
html, css, and jQuery work just about exactly the same as they did a decade ago, nothing stops you from using tools you already understand.
If it was up to facebook then react would be the only framework used on the web; problem solved right? In reality, there are different tools for different needs and if you don't understand the specific problems a tool was made to solve then of course you're going to find it confusing.
Just because a tool exists doesn't mean you have to use it. These tools were created to solve specific problems that the creators encountered, if you don't have that problem or don't like the solution then why did you pick the tool?
The most baffling part is the strange sense of entitlement as if people releasing their work for free on the internet is a burden to some because now they have to decide if they should use this free option.
If you want ES6, typescript, flow, components, css modules, SSR, hot code reloading, "universal" code re-use, postcss, bundling, automatic-code splitting, dead code elimination blah blah blah then that's on YOU. Don't blame the tools because you are enticed by their capabilities but not willing to understand why and how they work. If you don't care about that stuff then problem solved: don't bother with them.
I do wonder how much of the problem is that most of the tools and libraries comes out of organisations like Facebook and Google who have completely different constraints to the majority of us.
React might suit Facebook but it probably isn't a good solution for someone who's application only gets a few hundred hits a day.
It's a complete bifurcation of the Web's technology underpinnings. That will keep getting more dramatic. Developers and their pay will bifurcate similarly more and more as time goes on.
AWS has 150 services or so now. How many of those does a 12 employee small business need? None most likely. That business's site gets maybe 1,000 or 3,000 or 10,000 hits per month. It's an absurdity to throw all the new tools, libraries, cloud tech etc. at that. Most of the Web looks like that small site, most sites on the Web get very little traffic. So little that you could run it on a $5 Digital Ocean instance and have over 95% of the droplet's use capacity to spare.
Does my insurance agent, who operates his own small business, need machine learning? No. And to the extent he does, it'll be built into the tools provided by various insurance carriers, entirely hidden from his daily business operation activities.
So who actually needs all of these tools? You nailed it, it's almost entirely isolated to the 0.1% group, the Facebooks, et al.
> Does my insurance agent, who operates his own small business, need machine learning?
I have a friend who has his own navy. It's a small navy. He does like boats.
Once he had a men's yacht trip. There I met a guy and his son who ran an insurance agency.
Well, AI or not, one of the keys to his insurance business success was his ability to separate good customers from risky ones. Basically he knew nearly everyone in town, or at least every one of his customers, down to what they ate for breakfast or some such. That knowledge helped him get a good loss ratio and made good bucks for his business.
So, maybe what he did was not AI but real I!!
I'm sure that if someone had an AI tool that would help his loss ratio, then he'd us it!
For a second example, my father in law was on the local bank board. So, a guy in the community applied for a home loan. Well, at that bank, the loan application went to the BoD of the bank -- no joke.
Then at the BoD meeting, everything about the applicant got exposed and discussed right down to the details of his lifestyle. So, again, if some AI application could help that bank make better loan decisions, then likely they'd use it.
Lesson: That local insurance agent and that local bank both were really big on gathering, analyzing, and using all the data they could get. If AI could help, then they'd use it.
Well, it would probably be built into the insurance carriers' web stack. Dev teams need to keep up with the latest tech so they don't lose talent and can justify ever increasing salaries. So I think that's part of the reason you're seeing things move towards client side.
And you're right that most sites don't see traffic numbers to justify exotic AWS setups. I personally think most web businesses grow pretty linearly, so the focus on "overnight" scaling problems is more of a sales tactic than it is reality.
I do think you're underestimating the amount of companies that do need these tools, though. It's not as binary as "insurance broker" and "Facebook". Logistics companies, payment processors, restaurant groups, grocery stores, etc. all have pretty complex backend services and some of these tools are critical to even compete in their industries.
“Does my insurance agent, who operates his own small business, need machine learning? No”
If he has a fixed mindset you are right. But if he has a growth mindset and has the intellectual curiosity to learn what ML is and if he can apply it to his business and finds out that he could maybe he can increase his business 10 fold. Even if you take a stance that he is not interested in growing just the fact that living in this age and time gives him(or his kids) the option to learn/play with powerful tools at a click of a button is worth appreciating on so many levels
A major difference here is simple economies of scale.
E.g. a particular technology feature might cost $100k to implement in your business and get you a 10% revenue increase. For a large business, doing so is a no-brainer; for a one-person business doing the same thing is clearly a waste of money and effort. And there are many things like that, causing the bifurcation between the needs and common practices in large companies vs small.
That’s exactly what today’s cloud technologies bring to any small business. You don’t have to invest $Y to know if you can increase profits by x%. You can invest $Y/10 (even less in some cases) to figure out if this works.
If you zoom out and think about it for a second what most technology is doing today is making a small guy look big
Regardless of hits, React is designed for UIs that need to "React". That's the motivation behind the library. It's better suited to social networking applications than it would be to say an eCommerce store or a dashboard CRUD web app. You can still use it of course, but you probably won't be getting any of the main benefits because there's not much interaction with VDOM.
“The most baffling part is the strange sense of entitlement as if people releasing their work for free on the internet is a burden to some because now they have to decide if they should use this free option.”
Agree with this 100%. I keep hearing coworkers trash a particular open source project/framework with no understanding of what kind of problems it solves.
For me it's "premature optimization is the root of all evil".
Very often teams will use ages getting up on new frameworks to avoid a little hard programming, only to end up with hard programming wrapped in a huge framework they don't really grok and lots of incidental complexity.
Wordpress or whatever will make an email widget easy to source, but if that's only 1% of your project, why impact the other 99% without considering its impact? It's so easy for intuitive maps of the "hard parts" to dictate insanity across the whole development process.
I agree, but the opposite also happens: teams start by implementing something small themselves because the framework is so 'huge'. Over time, they end up with a semi-huge custom framework because they run into the same issues and feature requests the 'huge' open-source framework ran a few years before them.
It's a spectrum of complexity over numerous components, inside the context of a greater development environment which also impacts decision making. As boring as it sounds this is why I force myself to estimate as close to "everything" as best I can early in the project... Not so much to use as an estimate, but to map out areas where my intuitive understanding is inadequate, and to give some rough data to drive decision making. Mapping out the pain points at least gives you a semi-objective breakdown of where the actual work lies, and to what degree that pain will be mitigated/exacerbated by major frameworks. DIY has its limits ;)
The real problem here is that all these comp sci "geniuses" want to make a name for themselves with a "real" project and so they create all these garbage tools (compilers, pre-processors, etc) that make things worse by introducing and encouraging more complexity when just using plain JS would work better.
A lot of them are Java/C++ people with no experience in web development who see the simplicity of JS as a flaw and want to recreate the s--tshow they are used to working with because the complexity makes them feel smart and special.
That is just human nature though. The same argument has been going on for decades between C and C++ people. Nothing new here.
JavaScript static typing, promises, and modularization via imports are very useful—you just pay for them with a compile step. If you don't want those features, don't pay for them.
As many people here already said, just stick with your simple JS. No need to complain about anything because plain JS still works exactly as it always did.
> html, css, and jQuery work just about exactly the same as they did a decade ago, nothing stops you from using tools you already understand.
A decade ago, the requirements for supporting all/most clients (devices) were radically different. Different requirements mean different solutions and perhaps new tools must be used.
This isn't really true. jQuery's compatibility can stretch all the way back to IE8, up to the newest devices. If you require the web to be more than a document viewer, then you might in fact need some different tools; but HTML/CSS/jQuery didn't solve those if you're going back that far, Flash did.
But HTML/CSS/jQuery still work to solve the problems they always did. And they're still used in production today. According to W3Techs, jQuery is still present in 96.2% of the sites they could determine a JavaScript framework for in the Alexa top 10M.[1] And the very popular CSS framework Bootstrap still has it as one of its dependencies.[2]
> According to W3Techs, jQuery is still present in 96.2% of the sites they could determine a JavaScript framework for
But that doesn't mean jquery was used exclusively on these sites. Look at any major website, in addition to some modern framework, they will often include jquery for just a few old hacks (I've seen popular sites include 3-5 different jquery versions on the same page).
You have to do responsive design, and yes, that's a big change (and a big PITA) but that doesn't require flex or grid or React or whatever. You can't go all the way back to tables, but good ol' div-based design with appropriate CSS works just fine. The new stuff may make some things easier (or not), but if you don't feel like shifting paradigms, you certainly don't have to.
My Web pages are based on tables and have not even one DIV element! Why do I have to use DIV? Actually, I never saw any good explanation on what DIV did. What the heck is DIV good for? Why use DIV?
I think it's harder to make design changes to the page. You also end up doing crazy rowspan and colspan things. You end up with more html tags (though probably less css). It's probably fine. Though it's probably hard to make mobile-friendly. A lot of html emails use tables for layout because they can't trust the layout will work with divs+css.
Okay. So far I haven't had to use the span thingys.
For mobile, I'm just assuming that the users smartphone has a Web browser. For fitting on the smartphone screen, each page is just 800 pixels wide, and smartphone screens are that wide? But even if not, my pages are still usable
with only 300 pixels wide.
My most complicated page sends for just 400,000 bits which seems small enough. There are just two files, HTML and JavaScript (JS). The JS file is written by ASP.NET and is small and optional -- so I'm expecting fast page loading.
I didn't see any good reasons to do anything special or different for mobile. What am I missing?
The same font size on an 800 pixel wide smartphone as on an 800 pixel wide desktop screen will not be readable at all.
Go watch the original iPhone unveiling - https://thenextweb.com/apple/2015/09/09/genius-annotated-wit... - at 01:00:00 or so he shows the New York Times website front page. It's in three columns, like on desktop, meaning you can read nothing until double-tapping to zoom in. 10 years ago, because nobody owned a mobile, this was considered acceptable UX.
Now visit it today - https://mobile.nytimes.com - with a narrow window. The layout changes and the first headline is immediately visible. That can't be done in table layouts. If somebody visited a news website on a mobile today and saw a desktop-optimized layout, they would likely immediately leave.
Actually I have been guessing that smartphone users would somehow magnify my Web pages by a factor of two (2X) or three (3X). Using the horizontal scroll bar, they can get by with just the left 300 pixels. So, with 2X, they would be using 600 pixels on their screen; 3X, 900 pixels. Doing a Google search on smartphone screen pixels, the 900 seems fairly common.
I don't really see a way to present the
information to users with fewer than 300
pixels horizontally. My Web pages are so simple I don't see any way to make them
still more simple for smartphone screens.
The situation on tables versus DIV, JavaScript, etc. for me versus others appears to be: (1) I'm only developing one Web site and where the screen content is under my control from my design of my user interface (UI) and is especially simple. So, for my Web site, with just two main Web pages, I can do well with tables. (2) If I were Web site front end developer for many different Web sites, responsible only for the Web pages and not for the content, the site overall, or the business paying for the site, then too soon I'd find that tables were too limiting. So, instead, I'd use JavaScript to look up screen sizes, window sizes, pixels, the physical width of the screen in inches (millimeters, points, etc.) and then use DIV elements, more JavaScript, etc. to try to redesign the page for the screen of each user individually.
Net, from (1) and (2) what works for me for my just two Web pages for just my startup is not flexible or powerful enough for Web pages in general. Okay.
For the Apple announcement video, apparently that is blocked in the US on copyright grounds by NBC.
I didn't realize that Web page designers were going to so much trouble to accommodate tiny smartphone screens.
Really, for my Web site, getting a good user experience (UX) for smartphone users will be a strain unless, say, smartphone users are wearing special glasses or are very near sighted!
Having lived/worked through that period of time, it was due to rendering. The entire table had to be loaded before it could be rendered to the browser.
If your entire site was wrapped inside a table, nothing would load until it all did. If I remember correctly.
I'm not sure if that's still an issue with modern browsers, and our faster connection speeds, it if increased processing and network speeds have made it insignificant now.
My largest Web page sends for 400,000 bits and as two files with JavaScript enabled and just one file otherwise. So, the pages should load and "render" very quickly.
Every job I've had in recent years has required I use an overcomplicated toolchain involving React or Angular. For personal projects I avoid them like the plague but unfortunately I don't have that luxury when working on a team at a company. Please, point me to any full stack web developer job listing that doesn't mention React or Angular!
Like the author pointed out, many of the new "solutions" are just the same old solutions in a new wrapper. There may be edge cases that the new solutions helps with that the old solution couldn't handle, but that begs the question, why didn't we just improve the old tool instead of making a brand new one? This leads to a lot of outside pressures that fall upon developers/companies who are trying to stay relevant in the field. When everyone around you is moving to "B", do you want to be the one that is still using "A" because it works just fine? Do you want to risk being irrelevant in a few years to prove your point? Naturally, many people don't want to take that risk, and so they go on learning the new technology even though it's not really necessary for 95% of developers, and they start using it in their new projects and they get comfortable with it and then the whole cycle starts again.
> Like the author pointed out, many of the new "solutions" are just the same old solutions in a new wrapper
Nothing is new under the sun, something old becomes something new in a different context in a different time, same thing happens in music and fiction... so what?
> There may be edge cases that the new solutions helps with that the old solution couldn't handle
It's pretty condescending to reduce the work of many smart and passionate programmers down to "a bunch of edge cases". People put real work and thought into these projects based on their professional experiences and it's depressing to me that others can be so cynical that they're unwilling to imagine that maybe there's something they aren't seeing about why so many of their colleagues are excited about what these tools make possible.
> but that begs the question, why didn't we just improve the old tool instead of making a brand new one?
Setting aside the clearly obvious reasons why we don't (and can't, and often aren't welcome to) contribute to existing tools rather rather than roll our own - who is worthy enough to determine which projects deserve eternal tribute and which projects are allowed to even exist? Your question is absurd. Why don't all these hugely popular tools with active open source communities just disappear? Umm, why should they have to? Why don't all the people who have a problem with it disappear back to a world where they can manipulate individual DOM nodes to match their application state with imperative instructions... you know, the present world they live in right now?
> This leads to a lot of outside pressures that fall upon developers/companies who are trying to stay relevant in the field
I'm not understanding the complaint. "Pressure to stay relevant in the field" sounds a lot like "keeping up with advances in the field". I understand you don't agree that they are advances, but a lot of people disagree, including many individuals leading companies and organizations highly regarded for their engineering talent.
> When everyone around you is moving to "B", do you want to be the one that is still using "A" because it works just fine? Do you want to risk being irrelevant in a few years to prove your point?
If you're tasked with the responsibility of deciding which technologies are the most appropriate choices for a project and you decide to pick "B" because it's popular, rather than "A" because its a tool that you understand and claim is "just as good" as "B", YOU are to blame; by your own logic you're just giving yourself an intentional handicap so you can look cool.
> Naturally, many people don't want to take that risk, and so they go on learning the new technology even though it's not really necessary for 95% of developers
Who's to say what 95% of developers need? Some would say 95% of developers don't need javascript at all, so I guess that settles that.
You claimed that people who complain about these new tools either don't understand and are confused and/or entitled. I find those comments misguided. Your rebuttals to my post are valid, but I think you're still missing the main point of the original article.
I'm not trying to argue that new tools shouldn't be created, and I'm certainly not suggesting that their creators are not passionate or hardworking, so I was wrong to say that we should just improve the old tools. But it is worth questioning who should be using these tools - should the way everyone makes websites completely change because someone created a new framework or tool? There are always going to be new sites that push the limit of technology and will need new tools to get there. For sites like the author of that article creates though, which are often described as "brochure websites", those tools simply aren't needed, and yet there is conforming pressure within the community that pushes developers to make sites like that using the new tools, which is overkill and can turn something simple into something complex. If you're the person responsible for choosing these things, you will eventually face that pressure. If you're not responsible, you may not even have a choice. You can't pretend that people conform to social pressures.
> For sites like the author of that article creates though, which are often described as "brochure websites", those tools simply aren't needed, and yet there is conforming pressure within the community that pushes developers to make sites like that using the new tools, which is overkill and can turn something simple into something complex.
I understand what you're saying, but the bottom line is that "the conforming pressure" is illusory. At the end of the day the engineering team must deliver a product that works to specification and is not difficult to maintain, that is the only real pressure, there is no rational justification for choosing a tool that is less likely to accomplish that goal when a suitable one already exists. If someone is in charge of building a "brochure website" and they select a complicated SPA pipeline with many build steps as the solution then they are objectively doing the wrong thing and that's the end of the story, nothing in that scenario reflects on any aspect of the actual tools.
> You can't pretend that people conform to social pressures.
I don't, but those people are the problem, not the tool.
It's EMCAScript [0], the spec of which JavaScript is an implementation. New features will come out in the spec, and it takes a bit for browser's JS engines to implement them.
>Just because a tool exists doesn't mean you have to use it.
Most developers don't just grab their tools based on what they want to play with at the moment. Actual software engineering today involves working with other people and their code. Code reviews, integrations, maintenance, enhancements, technology overhauls, system decommissioning, working with vendors.
The fact that this simple reality didn't even cross your mind tells me everything I need to know about your opinions on tooling.
> Most developers don't just grab their tools based on what they want to play with at the moment. Actual software engineering today involves working with other people and their code. Code reviews, integrations, maintenance, enhancements, technology overhauls, system decommissioning, working with vendors.
And? What's that point you're making? If it's not your job to pick the tools then the point is moot because you'll work with whatever the technical leads decide, all you have to do is get to work.
I completely share the thoughts of the author of this article. However, I'm not sure if his proposed solution would work for most people. It's not that I want or like to use npm etc. - I'm forced to use them as it's the new default way of working with almost anything useful in today's web development work. An alternative would be to start from scratch - and then reinventing all these things again, making another full circle.
There could be another solution. A lot of today's complexity of the web stems from the fact that we're trying to design (web) apps using (HTML) documents. It's like building user interfaces in Word (without VBA). You can, but there are much better ways to do it. Why not to define a set of APIs for creating GUIs? Yes, I mean something like XUL which failed because nobody except Mozilla cared. Make it standard, make it easily themeable, and we can finally throw away this mess of ugly hacks used now to create intricate GUIs for which we have dedicated widgets on the desktop and which we have to reimplement on the web, with mixed results.
You're trying to conflate document design with UI design.
By the writing of the author, he is clearly doing just fancy documents. He didn't even touch the problematic issues you normally face in web development.
You can do pretty neat things with trivial html/css these days, where you needed quite a bit of JS just 5 years ago.
Platform GUI toolkits are designed for controlling an interactive program from the start, a very different usage scenario. They were never designed to be documents to be read from top to bottom. Traditionally, GUI toolkit almost never included fancy text layout boxes just for text display. To give you an example, a simple text label to be used next to a button almost universally could be of a single font with the same style throughout.
I wouldn't even consider this a limitation, because on toolkits with advanced theming (GTK/QT), this allowed for a very consistent layout across all programs, which is clearly a much better user experience for the user as opposed to styled individual applications. Somehow, this crucial bit of /actual/ usability /design/ was lost.
The irony? Current GUI platform toolkits are actually copying the document model of web pages instead, so that your layout skill set can be more easily transferred across systems. So you can finally style your button's label to your hearth's content. XUL is probably the first example of this.
As if "layout" was the major issue in desktop user interfaces (HINT: it's not).
Now we have GUI toolkits which are basically web views that maybe call some native code. In my opinion: a huge failure in engineering and user experience.
I guess it really comes down to the trade-off between customization and familiarity. IME in any given company there's plenty of people going to bat for the former, and hardly anyone that cares about the latter.
On the "sliding scale of giving a fuck" [0], there's usually plenty of graphics designers and managers whose job revolves around giving an '8' for customisation and branding, and most devs seem to consider usability at about a '5' relative to their other work, so they don't offer up a lot of resistance.
The fundamental problem is that you want one piece of (semantic) content to be presented on many different platforms with very different design approaches.
The current approach uses if-then-else conditions in CSS, and when that fails, if-then-else conditions in JS, and when that fails, complex JS to transform the DOM. The XML/XSLT approach, although clunky, might actually be better in many cases.
You can't honestly propose XSLT as a programming language in a thread where half the comments are about how shitty JavaScript is. I mean, JavaScript isn't God's gift to mankind, but XSLT?
I have a very hard time coming up with a worse programming language than XSLT, across all dimensions. INTERCAL, maybe? If XSLT had been proposed as a satirical esoteric programming language, people would've laughed and believed it. And probably made better tooling for it than the serious crowd ever did, just for the lulz.
> I have a very hard time coming up with a worse programming language than XSLT
What a straw-man argument. He clearly says "[t]he XML/XSLT approach", which is not advocating that XSLT is the best thing ever, but that we ought to consider that the people who developed XSLT had a similar problem to solve, thought hard about it, and came up with that. Many years later, it isn't out of this world that we could come up with a better solution. Arguably now there's more interest in such a solution than ever. For example, there are companies who have made generating PDFs for reports or bills their business model, because it's hard to do reliably with standard web tech. ePUB too? That would be all kinds of awesome.
So let's not dismiss XSLT and simply go back to the dysfunctional way it's currently being done. That said, of course XML et al are clunky, old and too enterprise-y - by trying to cover every use-case ever or having big corporations pushing their use-cases during the spec design this tends to happen. This seems to be a problem with the W3C in general, but they have to get their money somehow, and standards that nobody will use don't help either. Somehow we still ended up with JSON for the data serialisation use-case, which is pretty good. So there's hope. (The irony of JSON being at least inspired by Javascript does not escape me.)
> What a straw-man argument. He clearly says "[t]he XML/XSLT approach",
That's a good point. I think I'm so scarred by how much I dislike XSLT that I fail to read comments that are positive about it in good faith. Clearly a mistake on my part, thanks.
> I mean, JavaScript isn't God's gift to mankind, but XSLT?
Well... for just about any scenario where I would use XSLT, and demand the validation capabilities it provides, I can imagine the same functionality being delivered in javascript... I can also imagine trying to do QA on it when provided by a third party... thanks, but no thanks.
XSLT solves some serious problems in a way that satisfies some serious Enterprise demands. For any given issue a pure code solution will be better, but in aggregate you don't want your systems open to third party incompetence.
I disagree with the often-heard premise that HTML is a somehow inferior tool for creating GUIs that we somehow ended up with despite better choices beings available.
Yes, native GUI frameworks and widget toolkits like Swing, Qt, Cocoa and MFC have their place but it's precisely the nature and features of HTML (most notably: The link) that enabled most of the innovation we've seen on the web.
If building web apps was just about recreating the desktop experience but on the web doing that with HTML indeed would be a fool's errand. However, web applications today are so much more than their desktop equivalents from the 80s and 90s both in terms of what's possible with them and as to how accessible they are to developers.
Sure, developing a web app today is not as easy anymore as "View source", edit and see what happens but it's still a lot more accessible than developing desktop-style applications.
In my opinion, instead of throwing the baby out with bathwater and replacing HTML with something else (which frankly and fortunately won't happen anyway because let's face it: HTML is here to stay for some time whether you like it or not) we should try and think about how to make web development easy and accessible again.
I think tools like StackBlitz ( https://stackblitz.com/ ) are good first steps in that direction because they allow you to quickly try out and prototype stuff without having to care about setup and tooling.
What I'd love to see is the web equivalent of the C64 BASIC prompt, which provided you with an empty canvas to create something with right away.
> However, web applications today are so much more than their desktop equivalents from the 80s and 90s both in terms of what's possible with them and as to how accessible they are to developers.
Could you elaborate on that?
From the point of view of the user, an app from the 90s works much faster than Google Docs. From developer's point of view, using a visual widget in an app was as simple as dropping it on a form, and then setting some properties if needed, either visually or via code. Nowadays you can do it with Lazarus and it will generate code for different platforms.
Look at this from another angle: The fact that the most powerful web company today with some of the most brilliant minds can't create spreadsheet software that would work equally fast as its desktop counterpart already says a lot about the tools we're using. Some people can't acknowledge it and miss the point completely and say "browsers are slow", trying all possible optimizations - but these are all hacks, not solutions to the underlying problem.
Yes, the 90s app is faster but can it consume and provide data over a network? Does it afford collaborative editing? Sharing data with others?
You can now even use Google Sheets for creating web applications much like Excel has been used for creating desktop applications.
Lazarus and Delphi in general certainly are great tools but they're also limited in terms of what types of user interfaces you can create with them. There probably aren't many faster ways of creating single-user CRUD applications but once you have to roll out an application to multiple users who are supposed to use the application over a network and in a collaborative fashion things start to look different.
As for the other angle I consider Excel (and the concept of spreadsheet software in general) one of the single most remarkable pieces of software created so far. Creating a fully-fledged spreadsheet application is no small feat. Then, let's not forget, Google Sheets is free whereas Microsoft makes significant revenue with their Office products, which would explain their motivation to create the best and fastest version of their product they possibly can while Google seems to be trailing behind.
> Yes, the 90s app is faster but can it consume and provide data over a network?
Yes, AFAIK, though I haven't used the features much.
> Does it afford collaborative editing?
That's a new one, but probably less difficult to bolt on top of a desktop app than to make a desktop app in a browser.
> Sharing data with others?
Yes! Current model is actually a huge regression here. On the desktop, you have a file system. You can share files. In the cloud, each application defines its own half-assed abstraction over data storage, and you're limited to what the service allows you and/or the company was bothered to implement.
The problem with the web application is, unfortunately, a mix of multiple big issues. Browser becoming a worse-is-better incrementally evolved runtime for applications. A shitty technology (JS) used as the main language of said runtime. User-hostile business practices that became easy - and thus popular - to implement on the web. And the very popularity itself, which sucks out oxygen from more sane areas of computing and tries to port bad engineering everywhere.
> You can share files. In the cloud, each application defines its own half-assed abstraction over data storage, and you're limited to what the service allows you and/or the company was bothered to implement.
proposal-2-final-new-FINAL-draft-02-2018.docx isn't exactly sane data-sharing. With desktop environments you could use a version control system for that but that hardly ever happens in a consistent manner.
You can create walled gardens both on the desktop and the web. That's a question of ethics not technology.
It is, when you can freely move it onto a USB drive, or attach to an e-mail, an IM message, or transmit over countless other systems that have no relation with Microsoft Office.
> You can create walled gardens both on the desktop and the web. That's a question of ethics not technology.
Yes, but that's pretty much a tautology. Technology is all about making stuff easier, and web is pretty enabling when it comes to walled gardens and other unethical conduct.
Ultimately, the web is what killed end-user open source. A web application is an ultimate anathema to both open source and free software - you don't get to run the program as you like, you can't inspect it in any way (even if it's "open sourced", you can't verify if this is what really runs on third-party server), you can't distribute it, you can't modify it, and to top it off, you no longer own the data you work on with said software.
> Ultimately, the web is what killed end-user open source. A web application is an ultimate anathema to both open source and free software - you don't get to run the program as you like, you can't inspect it in any way (even if it's "open sourced", you can't verify if this is what really runs on third-party server), you can't distribute it, you can't modify it, and to top it off, you no longer own the data you work on with said software.
On the other hand, there are many people who are aware of that and are actively using, developing and promoting the so-called "self-hosted" solutions - that is, completely free and open software that is in direct competition with closed web apps.
Have a problem with a commercial, closed solution? Look here:
https://github.com/Kickball/awesome-selfhosted
Still haven't found what you need? You're always free to create one on your own. So you can't really argue that it is the web that "killed" end-user open source as it's very much alive, from VLC to WordPress.
> Technology is all about making stuff easier, and web is pretty enabling when it comes to walled gardens and other unethical conduct.
The web enabled us to reason about walled gardens in the first place. Before the advent of the web there was no talk about walled gardens simply because everything was a walled garden.
> Ultimately, the web is what killed end-user open source
That implies that end user open source had really lived before. For end users open source while not exactly irrelevant never has played a huge role. One reason for that perhaps is that there doesn't seem to be a long-term viable business model for open source desktop applications.
> A web application is an ultimate anathema to both open source and free software - you don't get to run the program as you like, you can't inspect it in any way
That's the case for pretty much any client-server application. The Affero GPL for example tries to remedy this but again that's more a question of business model rather than technology.
I don't understand why you're downvoted, your concerns are valid. I don't see any problemw with sharing data over the network, but I don't thin collaborative editing of a standard table widget via network is possible in the current version of either Delphi or Lazarus. However, in the case of Google Sheets, the biggest advantage is not the ability to edit the sheet by many people at the same time (which causes new problems for anyone who tried), but the ability to share it with others once so that everybody has access to the most recent version, forever. This is definitely possible to implement in a RAD from the 90s.
> an app from the 90s works much faster than Google Docs
This is not really a technology limitation as much as it is a product and economic limitation.
Google docs works like it does because it is "good enough" from an economic perspective. Improving the performance would not increase profit so it is not done.
Much of what people complain about with web software being crap is the same issue. Crap is more profitable so that is what companies make.
HTML is inferior than a technology that is purpose built. It was not originally designed to handle the job it does today. It is possible to create a much better user experience with eg. C# using some network code to talk to the server than trying to shoe horn an application over HTML just because it hides the low level complexities of E.g C#/C++ communicating with a server. This is a classic case of HTML/web apps are easier to produce (does that even make them inferior?) than custom built software, but it is more efficient to develop a web app, and therefore that is what business/industry has done.
HTML is not inferior it's different. In the late 90s some people said the same about Java and Java applets in particular. The UX of those however often was significantly worse than that of roughly equivalent (but at that time less dynamic) web applications.
Apart from the usual benefits like being able to easily link to and consume resources HTML affords you a great deal of flexibility. Desktop UIs for very good reasons both follow OS-specific style guides and if cross-platform capable also have to settle for the lowest common denominator.
As for your last point: Absolutely. Being accessible and easy to create perhaps is the single most important feature of HTML.
Tools can be used beyond the area they were originally intended for and still be useful and appropriate.
Tim Berners-Lee probably didn't have single-page applications in mind when he invented HTML but hyperlinked documents are also inherently more dynamic and application-like than traditional documents. Just think about HyperCard, which is a similar concept HTML and the World Wide Web were inspired by.
So, yes in a way indeed HTML was also built for many of the purposes it's used for today.
C#, and maybe all programming language, are not designed for structuring documents inside a browser either. That is what HTML is for, not display or applications or communication, etc.
I'm not sure I've seen any "user interface innovation" done with HTML.
Pick a book on GUI interfaces of the 80ies (for example: Computers Graphics by Foley & al), and see that pretty much all UI paradigms themselves were pretty much explored back then. The concept of the "hypercard" was already there.
HTML just improved on the presentation of it, often worsening everything else. Somehow web apps lowered the expectations of what a computer /should/ do so much that usability itself became an afterthought.
Some of the best designed apps on the web mostly ditch the DOM and layout everything in JS. Hardly "innovative".
I'd say that the web page itself is a pretty innovative concept. The concept might've existed before (Apple's HyperCard dates back to 1987 for example) but the web expanded on that by making use of resources distributed across the network.
There have been many smaller improvements, too. Google's Material Design for instance.
> There have been many smaller improvements, too. Google's Material Design for instance.
Could you elaborate on that? I.e. how this is an improvement, and over what? Serious question.
My overall impression is that it promotes dumbed down interfaces that maximize wasted screen space while minimizing amount of useful information displayed. But I might have just bad luck and constantly encounter applications using Material Design wrong. How does a good Material Design application look?
The material metaphor and the purposeful use of animation ("Motion provides meaning"), dimensions and visual perspective in my opinion is an improvement over merely arranging information in grids.
It's a fresh approach to displaying information in a meaningful and consistent manner.
Both the new Google Calendar and Contacts application are decent Material Design applications in my opinion.
When I'm a user, I like the old, simple HTML UI, and I've nearly always just deeply, profoundly hated and despised
> the desktop experience
To me, the whole "desktop experience" was based on some nonsense from Xerox PARC, that (1) the screen should be a metaphor for a traditional desk with several sheets of paper, (2) what was on the screen were representations of various objects that a user would manipulate directly using the pointing device, and (3) how the screen UI (user interface) worked should not be explained or documented but should be intuitively obvious, as obvious a sheet of paper on a real desk, and otherwise easy enough to learn just by experimentation.
Well, for a very well designed UI for, say, a microwave oven, it worked, yet my microwave oven did come with a nice user manual.
But for the goal of all of computing, IMHO, the Xerox PARC model and assumptions are a huge pain in the back side.
E.g., for Microsoft's Windows Media Player 12 with Windows 10, I tried for hours, clicking, and clicking, basically enumerating and traversing all the UI before I finally resorted to my old favorite -- just put the mouse pointer, trial by trial, at nearly every point on the screen and there do four things, left click, right click, double left click, double right click, and see what happens. Don't look for any links, push buttons, controls and, instead, just throw clicks at the screen, exhaustively. Finally via such meaningless clicking, I was able to get some new options and, eventually, play an old audio CD but was not able to play a movie DVD. Some "user experience".
To me, the situation is similar for a lot of common desktop software -- the UI is not described, documented, or obvious, and too often a LOT of experimentation is needed to figure out what the heck was going on.
My UI Excedrin headache #948,223,594,667 was just last week with Outlook from Microsoft's Office.
So, I wanted to use the old Microsoft command XCOPY, with some carefully selected options in a script in Rexx, to back up the directory tree that contains all of MY (not Microsoft's or HP's ) data on the computer, copy the directory tree to an external disk drive connected via USB (universal serial bus). So, I started the backup and in the morning discovered that the backup had failed.
Failed? The computer and the external disk drive are quite new, and XCOPY and the options I was using are quite old and long perfect, so what the heck could have failed? I've been doing XCOPY backup and restores for 10+ years back to Windows 2000. Before that I was doing similar operations with similar software on OS/2 and then Prime computers.
So, the last few lines on the screen explained the problem: The PST (personal storage or some such?) file that I have Outlook using was "locked". The actual message was the dreaded (from what can see via Google)
File creation error - The process
cannot access the file because
another process has locked a portion
of the file.
So, but the only program that could have that file "locked" was Outlook, and as far as I knew it was not running. Then I looked at the output of the latest version of Microsoft's Task Manager (Windows 10 does have one although it is very different from what was on Windows XP) and saw that a program OUTLOOK.EXE was running.
So, I told Task Manager to "kill" the program and started XCOPY again. So, then the XCOPY run worked fine!
Then, presto, bingo, the next day trying to run Outlook gave
Microsoft Office Outlook has
stopped working
A problem caused the program to
stop working correctly. Windows
will close the program and
notify you if a solution is
available.
Well, I decided not
wait for a notification!!!!
I renamed that PST file
and copied to the old
name an old PST file
and found that Outlook
gave the same message.
So, the problem was not the
PST file. So, the bad
memory Outlook was using
about had to be in the
Windows Registry.
So, maybe I could do a
system restore? Looking
around, such is still
available. So I did
a system restore.
Then Outlook started right
away but also said that the
PST file (the one Outlook
was using before this mess)
had not been closed properly
or some such, checked the file,
and found nothing wrong and
now Outlook seems to be
working again.
So, before doing a backup,
do a system save. For Outlook,
try to have it not running.
Why was Outlook running when
I'd long since closed it?
Okay, someone sent me via e-mail
an appointment. A first
ever for me. Of course, no
way do I want Outlook involved
in appointments. But, then,
with that appointment, Outlook
kept giving me notifications.
The first backup attempt was
actually after the appointment
time and date, but somehow
Outlook, when healthy again,
reminded me again about the
appointment. So, apparently
if there is an appointment,
Outlook will not stop but
just keep running so that it
can send notifications about
appointments.
So, before doing a backup,
go into Outlook and delete,
cancel, eradicate, obliterate,
get rid of, destroy utterly
everything about appointments.
I JUST want Outlook to do
e-mail, JUST e-mail, JUST
simple, old SNMP (simple
network mail protocol) and
POP3 (post office protocol
3) e-mail. And, actually
I want all the e-mail
to be just simple, old
ASCII text or UTF8.
For more, use attachments
as in MIME (multimedia
internet mail extensions)
with base 64 encoding, etc.
So, for this cause and cure,
are just throwing stuff
against the wall, hoping,
causing problems, getting into
a system restore with some
work lost etc. Bummer.
Huge bummer.
No, Xerox, Microsoft, your
UIs are NOT "obvious". No,
you NEED documentation.
But, for old, simple HTML, say, without JavaScript, for some 100+ million such Web sites in the world, some trillion+ such Web pages in the world, and for 2+ billion people in the world, modulo natural language, every person can understand every Web page and Web site right away, no users manual or experimentation required.
Lesson: On the desktop, the Xerox PARC stuff was an open door for chaos; on the Web, the simple HTML with its few, simple, well understood controls cleaned up much of the chaos and provided discipline that greatly helped UX (user experience).
So, for the goal of having Web pages more like desktop applications, UIs, UXs, no thanks.
Yeah, I agree with both you and the article. The biggest problem with website design seems to be that it's all layers on layers on a base that wasn't so great for design in the first place.
The other problem is we're doing this weird kludging an app to do something on the web even when we don't need to - even when we're just presenting text.
I know people have different needs, and that reasonable people can make reasonable choices and end up in very different places. What I don't understand is how anyone could end up in a place where this kind of website is ok. Give me a pdf; give me plain html and css.
https://fermatslibrary.com/s/shelling-out-the-origins-of-mon...
Website, ha! There's a webpage pretending to be a programming IDE; even though it needs GBs of memory just for its overhead, it's hugely popular.
shrug (Ditto anything else electron-ish)
There aren't much better ways of doing it. At least with existing alternatives. Have you genuinely tried the alternatives? I think the web has a lot of shortcomings, but it's still pretty great.
We have a set of APIs for creating GUIs. It's called the web platform. It's all standardized with multiple independent implementations, and easily themeable.
You're forgetting the many different targets that the web platform has. How should different widgets look and behave when handling different input types and screen sizes? Trying to get vendors to agree on anything of this scale is like trying to herd cats.
>simply npm your webpack via grunt with vue babel or bower to react asdfjkl;lkdhgxdlciuhw
>[...]
>I had to install a package manager to install a package manager.
And that's coming from a designer, not a programmer.
A few years ago I had to take over a project that required installing something like 6 different package managers, 2 build systems, and a dozen different languages (counting things like jade and coffeescript), including dependencies that somehow required conflicting versions of the same libraries! (It took building pieces of it on 2 separate VMs and then merging them to get it to work.) All to build what turned out to be a simple little web site that in the end was basically 12 static pages and a simple form. That doesn't make things way easier.
When I started programming, the key important things were to focus on getting the data model accurate, getting the business logic correct, validating input properly, and producing the desired output. Now that is maybe 5-10% of our workload, the other 90+% is dealing with dependencies, build tools, frameworks, 57 layers of generic abstraction, and all the fragile interconnections and leaky abstractions and compatibility issues between all of those things needed primarily just to simply display a page of content or handle a CRUD form.
Sure, they're beautiful and interesting from an intellectual standpoint, and when they're working properly, they do make things that were once quite difficult a lot easier. But they also add a lot of complexity, require a lot of maintenance, and make the simple things much more complicated. Often, it's as if we're flying a squadron of helicopters down to the corner store to get milk (because isn't that cool and fun?!), and by the time the operation's completed and we've returned home and got all the helicopters repaired, we realize that we forgot the milk, or it's already spoiled, or we ended up with a potato instead.
I do love playing with the new toys. React is really cool, a lot of the new stuff is interesting. But all those layers, all that indirection, all that distances us from the domain data and business logic can make it a lot harder to solve real problems and produce real value. Sometimes I just want to build something and not have to deal with all that mess.
One of the best things about working for myself is that I write all my web stuff in vanilla JS.
While I occasionally make errors, they are easy to identify, understand, and debug because the native features of JS are well-understood by modern browsers.
Sometime in the last decade, modern web development moved on without me. I can no longer recognize what people are doing with all of these package managers and why they are doing it.
I guess from a corporate stand point, it makes sense. You'd want your developers to be like widgets or sprockets, easily replaceable. Hot swappable. Otherwise these guys might build Daedalus-like spaghetti-code mazes and no one will ever be able to replace them.
As a one-man operation, I'll stick with vanilla. It's easy to understand and it works forever.
> I guess from a corporate stand point, it makes sense. You'd want your developers to be like widgets or sprockets, easily replaceable. Hot swappable. Otherwise these guys might build Daedalus-like spaghetti-code mazes and no one will ever be able to replace them.
Corporations got owned here, though. The web ecosystem managed to create this whole big spaghetti of a toolchain, and now they get to command great salaries to keep it all working. A vanilla JS developer would actually be more of an replaceable widget or sprocket than a modern web developer, but modern is now "industry standard", so corps don't even know they're overpaying.
I guess it depends on how complex the app is, but pulling vue into a page is trivial and gives you a lot of functionality without having to use vue files , es6, or a bundler. After building things with vue and the reactivity it gives you, writing traditional js code to turn knobs manually seems tedious. Vue (or react) eliminates ui state bugs which was probably the biggest source of bugs for me. I fail to see how, under any circumstances, jquery is a better option for handling the dynamic portions of your page .
Sure that works, especially if you tend to write more web sites than advanced web applications. But that is true for back end as well, a one man operation can write Python or Java in a style and using libraries from 10 years ago and it would work perfectly fine. But depending on what they are doing they might not be as productive as they could be.
If you want to try for example React it is incredibly easy to get started. Just if you want to check out what the fuzz is about.
This made me chuckle, since modern Python and Java styles are very, very similar, if not identical in places, to those of 10 years ago. Some of the libraries have changed, but many are the same as well. Shoot, I can still run Python code I wrote 10 years ago on the latest version (yep, that means something originally written for Python 2.3 can run fine on Python 3.6).
And no, that doesn't make Python and Java old hat or redundant.
You can run 10 year old JavaScript as well, no problem. But Java written today is pretty different from Java written 10 years ago and the Java frameworks are very different.
My point is that you can write code in the style from 10 years ago in any stack but for some reason people seem to take pride in it in the JavaScript world just because they cannot be bothered the actually learn modern development. Not to mention they tend to exaggerate the difficulty of getting started. Compare the tooling, build chain and language features of a JavaScript stack with for example Java. It is not like the JavaScript one is more complicated.
You don't need something like React if you are doing a simple web page but a lot of people ARE building more advanced web applications these days and then it is probably best to just suck it up and learn a modern stack because the old ways of development is not really suited for it.
> Sure, they're beautiful and interesting from an intellectual standpoint
constructing an application which consists of updating a table and persisting it in a database for business tomorrow should not be a high art.
Most enterprise / business applications are not much more than glorified form fill-in, and the simple ones don't really deserve the multiple layers of abstraction. If you don't believe me, recall the relief of being able to "just edit the damn data" in the django admin tool when the regular application is misbehaving.
That is because there was an explosion of possibilities with web development and a lot of different solutions where created at the same time.
These days things have settled more and most technology stacks have one preferred package manager (almost always npm) and one build chain (webpack being the most popular).
Yes, there have been confusion but there is a reason why and it has brought along web development that is so much better than it used to be and it is usually not very complicated these days. If you pick a stack you will usually have a cli that handles everything for you.
Did anybody notice that the 1997's Hello World example https://frankchimero.com/writing/everything-easy-is-hard-aga... still works? Open the most easy built-in text editor on your system (even on Android one should be able to do that, isn't it), save it, open it with your browser locally.
In some aspects, the evolution of the web is similar to what the C language ecosystem experienced. It was dead simple in the beginning --- however the "Hello World" is still the same! Today's users are more demanding in terms of user interfaces and you will not go far without libraries. Same story with building modern "reactive" websites.
I personally like that CSS got more powerful, it allows us to build modern websites without JavaScript. That wasn't possible 20 years ago.
Virtually none of which is considered valid in HTML5, and which probably doesn't render properly in some modern browsers. Mostly this was less to do with "power" and more to do with a web standards turf war about forcing layout out of markup, despite the available CSS syntax and early 00s browsers struggling a lot with basic grid layouts. We've now come full circle with a lot of modern frameworks end up working with HTML markup like
which is remarkably similar except that it involves a library, custom css and quite possibly javascript polyfills or autoprefixer tools if the framework or parts of the code is written in modern CSS, all to do what HTML4.0 and late nineties browsers did natively. (And you had CSS font and colour selection if you wanted it then anyway)
That's not to say that there haven't been useful innovations like media queries and rounded corners (making them with graphics was horrible) or that a global CSS file doesn't make a lot of sense in most use cases. But there's an awful lot of wheel reinvention that's happened to vanilla layout markup.
I second the full circle. However, to be honest, LESS/SASS allows us to use semantic class names, so we can do better. This was hip 4 years ago with Bootstrap and I guess today the young folks uses CSS3 and therefore can get rid of the intermediate compiler.
20 years ago was 1998. CSS was the modern thing. JS was called DHTML and was used for mouse trailing bouncing balls. XMLHttpRequest debuted natively in IE6, which was released in 2001, before that, it was ActiveX and nobody used it.
> CSS was the modern thing. JS was called DHTML and was used for mouse trailing bouncing balls.
Javascript was called Javascript and was used, mostly, for form validation. Dynamic menus, animations... - all of which you couldn't do with CSS alone - were called DHTML. You could even use Javascript in the server.
> [...] before that, it was ActiveX and nobody used it.
Plenty of people used ActiveX and it was useful, sometimes, although it limited you to IE. But you are forgetting two of the most widely used technologies of the time: Applets and Flash. Fortunately both are out of modern web development.
> You did create modern sites with CSS, without JS.
You did create sites with CSS, "modern" sites included JS and DHTML.
Then, as now, I found that most people complaining about Javascript were really complaining about bad coders and bad implementations; The browser's DOM back then and the mess that is NPM today. The language itself has bad decisions (weak dynamic types) and good features (functional capabilities), exactly like every other language out there.
I think it has a great deal to do with abandoning something simple not because it's not good enough to do the job, but because of fear of being left behind, fear of becoming irrelevant in a world where "new and improved" is introduced at an ever growing frequency.
Sure, improvement is a good thing, but the question I think we sometimes forget to ask ourselves is when does the cost involved in certain technological improvements (more learning curves, higher process complexity, energy required to stay on top of the rapidly changing technologies and tools etc.) start to become higher than the benefits produced by the so called improvement.
I've been in this field long enough to see how many times hype beats common sense, unnecessary complexity beats simplicity, and emotion beats logic (heck, I'd bet it's a common theme outside the technology sector as well) but I'm optimistic - the bottom line is that things are improving and even though things sometimes seem circular, it's more of an upward spiral.
> There’s a voice in the back of my head saying we’re stuck in a loop and it’s repeating. We’ve completed a lap on a cycle which will go around forever. Another approach for layout will come along five years from now, it will probably resemble floats, and not knowing how to clear a float will bite me in the ass for the second time in my career.
This is what I feel like everytime I try to keep up with web tech... For crissakes, the last training I went to had a session on Razor Pages, which set off my PTSD from years of doing ASP.NET WebForms, back before we decided that was a really awful, painful way to do things.
This is an excellent piece of writing. The aphorism "Go slow and fix things." is brilliant. I'm stealing that.
I implore people reading this thread to watch this Alan Kay video from 1997, where he rather predicts (albeit perhaps implicitly, if not explicitly) that we will reach the situation we are in today.
There is a quote from the talk which rings true with many of the comments here "HTML on the internet has gone back to the dark ages, because it presupposes that there should be a browser which understands its formats"
I have found the odd nit with the article:
"In one way, it is easier to be inexperienced: you don’t have to learn what is no longer relevant."
I think he might mean unlearn, but it's a bit ambiguous. :-)
Dr Kay has been loudly telling us for a long time that we are on the wrong track whilst having already delivered a complete alternative. One can only wonder what his perspective feels like.
This is so true and I'm certain it's related to the noticeable downgrade in web performance and usability over the past five years. So many sites are flabby and slow now because they're retrieving countless packages from CDN's, each time of course with a ssh handshake, etc etc. You can see endless retrievals flashing on the bottom bar, sometimes literally never stopping, as the site keeps doing one thing after another to anticipate what you might want to do, load new content, or whatever. I find the web only barely enjoyable to use anymore. Even the simplest things seem to blow up now, e.g. very often I get "not found" for the Google homepage. Huh? That one's probably on me somehow, but I'm not doing anything different that I know of, but what has changed that I know of is the extreme increase in complexity of internet delivery and programming. And I will just vent one more pet peeve. Not EVERY part of a web page needs to pop something up in your face when you put the mouse over it. Thank you.
Actually that’s pretty much what I would expect if I tried to build interactive applications on top of a declarative document format whose standardization was co-opted by the largest advertisement company, while working with novices straight out of last week’s coding bootcamp eagerly reinventing the wheel out of their lack of experience and mentoring.
If that site is good enough for one of the worlds most valuable corporations, maybe we're just massively over-doing the entire web?
Side note, I laughed really hard when I saw that they had a god damn ad hard-coded on the page hahaha. That's how you end up one of the richest investors of all time, waste nothing.
I came across that site probably seven years ago when I was going through Fortune 100 websites and looking at how they were approaching mobile web design, and I had a good laugh at this one. Glad to see they still haven't changed. :)
This is my experience of web development, every time I return to it.
I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered.
JavaScript is a very badly designed programming language (yes, even in its modern form), which I think has caused a lot of problems. Many JS developers don’t know much about programming language design, so they can’t see how bad it is, and they make matters worse by not trying to abstract or use JS in a way that reinforces good PL design methods.
If you recognise JS as a terribly designed language, then the last thing you would imagine doing is widening its use. But that is exactly what node.js does. You should instead isolate JS and minimise its use. So red flag - something has gone wrong here.
It also feels that many web ecosystems have an over-inflated sense of self-importance. This has led to many competing frameworks for the same tasks, that try to do everything. Things are not pythonic. There appear to be an excessive number of package managers involved. There were already plenty of package managers out there - inventing new versions of existing tech makes it harder for everyone and is usually a red flag that someone somewhere is making bad decisions.
I need to build a website soon and I’m dreading the front end. At the back end I can use range of solid and well designed languages and technologies, but at the front end I feel like I’ve got to choose the least poor of a bunch of crazy options. If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend should approach web dev that would be massively helpful. “Sane web dev to minimise the impact of the Web Dev CSS/JS disaster on your life” would be my favourite O’Reilly of all time.
> If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend should approach web dev that would be massively helpful
Sounds like Elm [0] (pure, functional, very very easy to start with but lacks abstractions), Purescript [1] (pure, functional, powerful, the best language for the web right now, imo) or ReasonML [2] (functional but impure, familiar syntax, focused on pragmatism) would be right up your alley.
If you're ok with a dynamic language (i.e. strike rigour), then look no further than Clojurescript [3], Clojure's [4] little web brother. An elegant and simple Lisp, it makes almost all other dynamic languages completely obsolete.
There most definitely are sane options for developing for the web if one is willing to use a compile-to-js language.
Not everybody wants to spend next 5 years learning thinking bottom-up, mastering category theory, monads and all that for such a task like writing a silly webpage you wouldn't rather be doing.
[rant] Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology. I program in Haskell/Scala but pushing functional programming everywhere is IMO just insanity and everybody is silent about many warts and weirdness of purely functional programming. [/rant]
"Right now, any Elm developer can examine Elm code that another developer has written, and fully understand what is going on. I consider this a major thing that Elm has got right."
And
"Elm is targeted at the main source of users it has — Javascript developers. Javascript developers may be familiar with typeclasses, but it is less likely that they are than Haskell developers. Alternatives like Purescript provide more abstractions and powerful type systems suited to those from the Haskell community. There are many of us Haskell users who sit happily with Elm too."
Elm favors simplicity and pragmatism over academic FP lingo. You need to change your way of thinking a bit, true, but it benefits the architecture. And it'll take weeks, not years!
You will not find the words "monad" or "category theory" or "algebraic datatype" used in the Elm docs.
The guide is probably the best resource to get started: https://guide.elm-lang.org/ It introduces you to the language as well as the concepts / architecture.
> Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology.
True, FP excels at concurrent programming, but that's far from its only strong point. I'd propose that React-like architectures (which are based around a pure Model -> View function) and functional languages are a match made in heaven.
I'm surprised that you think FP requires mastering category theory. Au contraire. It's perfectly possible (and indeed easier for programmers) to understand the abstractions that Haskell and Scala pioneer (higher-kinded types, and things like type-classes as well as monads which are basically enabled by HKTs) without category theory. It is true that monads were discovered via category theory, but in retrospect programmers could have discovered them -- after all they are (simplifying a bit) merely a way of generalising composition.
Scala and ML-variants like Ocaml, F#, Reason.js are perfectly good
imperative languages. They don't force you to go purely
functional. I always recommend that my students (whose first language is Java) start by treating Scala as a "nicer Java", and then slowly explore Scala's more powerful features. Indeed, I'd argue that Scala and the aforementioned
ML-variants are (slightly) better general-purpose imperative languages
than the Javas, Pythons, PHPs and Javascripts of this world, because
they are more consistent, they have types/type-inference, and their
statefulness fully supports higher-order state and powerful
modularisation without restriction, not to mention pattern matching.
Being able to use functional idioms without compromise if and when desired (including, but not restricted to, pure functional
programming) is another benefit of Scala and ML-variants.
Monads existed before their connection to category theory was discovered (by Wadler and company), they just didn’t have an elegant way of describing or naming but. them, and definitely the connection allowed them to push them more.
The biggest problem of very functional code on the web is simply debugging it. So much control flow is buried in compositions that there isn’t much to grab on in terms of break points or variable inspection. Pure languages exacerbate this problem by making state more difficult to dig out and pin down at run-time.
Exactly. Debugging is one of the biggest problems with FP, and when you hear some prolific Haskell hackers talking about no longer being capable of understanding code they produced 10 years ago at the peak of their mental performance, it's difficult to commit to it exclusively.
> Debugging is one of the biggest problems with FP
I don't see why that's a problem with FP and not just the lack of tooling in most FP languages. Debugging in F# via Visual Studio is a breeze, and OCaml's time travelling debugger looks pretty good.
I guess if you start using nth-order functional compositions and everything is a recursion, it's super difficult to figure out what is going on from e.g. stack traces or just simple log statements. And often FP programs are more-less solutions to "puzzles" and to understand the solution you need to keep that "puzzle" on mind. Now what are you doing if you have multiple levels of "puzzles" at the same time and you need to connect two separate subsystems via some deep-level information exchange, given there are no mutable variables/singletons for you? I am sure anyone taking FP seriously hits this kind of problems regularly and they often take long time to come up with satisfactory pure implementations.
Just a clarification for anybody else who might be reading this: there absolutely are mutable variables in pure fp languages like Haskell, you just have to explicitly ask for them (and reflect that fact in the type), i.e:
do
x <- newIORef 0
writeIORef x 2
print =<< readIORef x
will print 2. In fact, I'd argue that many times writing programs with mutable state is actually easier in Haskell/etc, especially when it comes to concurrency where something like software transactional memory [0] is invaluable (and more or less practically unusable in other ecosystems), if it fits your constraints.
For F#, is it a debugger designed for F# or just good integration with VS’s .net debugger? If the latter, I should mention that the problem remains even when using C# if your code gets too functional (e.g. getting rid of some LINQ for debuggability is a common trade off).
Indeed there are some quirks in VS 2015 even in C#, like writing a function as a generator isn't as pleasant as it could be. Haven't tried VS 2017 yet. I think we're a little spoiled on .NET though, we've forgotten how bad debugging is in other languages!
Interesting. Where do you hear that? What I've heard (and experienced) is that Haskell makes is easy to come back and understand code written a long time ago (because the language allows one to structure code very clearly).
I'm not a historian. It's certainly true that monads or monad-like
things where discovered independently in many context. This isn't even
surprising, given how natural, and trivial in a sense monads are. But
the systematics realisation of the concept and its wide applicability
comes from algebra and the efforts to recover algebra
categorically. Let me quote from Wadler's [1]:
The notion of monad comes from category theory [...] It first arose in
the area of homological algebra, but later was recognised (due to the
work of Kleisli and of Eilenberg and Moore) to have much wider
applications. Its importance emerged slowly: in early days, it was not
even given a proper name, but called simply a "standard construction"
or a "triple" [...] Eugenio Moggi proposed that monads provide a
useful structuring tool for denotational semantics [...] He showed how
lambda calculus could be given call-by-value and call-by-name
semantics in an arbitrary monad, and how monads could encapsulate a
wide variety of programming language features such as state, exception
handling, and continuations. Independent of Moggi, but at about the
same time, Michael Spivey proposed that monads provide a useful
structuring tool for exception handling in pure functional languages,
and demonstrated this thesis with an elegant program for term
rewriting [...]. He showed how monads could treat exceptions [...]
and non-deterministic choice [...] in a common framework.
[1] P. Wadler, The essence of functional programming.
Yeah, I like the balanced approach - I'd love to use whatever programming mode that is available to me when I see fit, whether it is imperative mode, functional mode, self-modyfing mode, GOTO/JMP-mode, everything-is-a-modifiable-object mode, Deep Learning-assisted mode etc. I just don't like when somebody forces on me "the one right way", which was the feeling I got from the parent post.
I've been learning Elixir (a functional language) for a new project I'm working on and even with only being able to allocate 20-30 minutes a day on it, I don't feel like I need to relearn everything. This is with no prior functional language experience, just a bunch of general experience with Python and Ruby.
I have no formal CS education and while I've heard the terms category theory and monads before I have no idea what they are. In my mind, monads are some Haskell related meme and category theory is thinking about whether or not to use categories on a blog engine.
I found Elixir to be curiously easy to adapt to. I spent like 15 minutes glancing Elixir's documentation and now I'm running a Phoenix based web app (somewhat comparable to Rails but not really) following an "error based development" work flow.
This is where you try to do something, completely fail at it, look up the answer and figure out how to apply it. I don't even know how most of Elixir / Phoenix works yet I'm able to accomplish real things.
After spending 15 minutes reading Phoenix's docs on routing, I actually feel like I understand Phoenix's routing system better than other frameworks in different languages that I've worked with for years. This is partly because it's so easy to just trace a function call back to another function call and understand what's going on (plus their docs are badass).
Immutable dats structures in CLJS pairs well with react type frameworks. Trying to make js pretend it supports immutable structures is what turned me off the most about react/js
I ended up going with vue which uses mutations instead of having to return structure copied from functions.
Just made more sense to me. Maybe MobX does this for react? Idk
That's incredibly high praise for Clojurescript. It's got some great features but it has flaws, too. I feel like many people new to web dev would be more confused setting up a Clojurescript project than they would be with JS. It was a lot of googling when I did it a couple weeks ago, and that's coming from someone who has done several times over the years (what's this boot thing, I was told lein was the best thing ever?).
Those are all great languages. It is important to realize that they will increase bundle sizes, which is a common rant about web pages these days. Hello world in Bucklescript/Reason, for example, is 23 KB (anything touching the std lib at least), Elm much bigger than that. My friend's 500 line Clojurescript/Reagant app was over 500 KB uncompressed, 5k lines of JS will come in at 140 KB.
It's worth being aware of the tradeoffs you are making, because often when people are selling new tech they tend to overstate advantages and understate disadvantages.
> It is important to realize that they will increase bundle sizes
Absolutely, and it wouldn't make sense to program a tiny static webpage in e.g. Purescript.
That said, to put that into perspective, pulling 350 npm modules for a bigger project is kind of the norm now. Using compile-to-js languages will incur more overhead still and it depends on the project whether that's acceptable or not, but many times it most definitely is (also, I hope webassembly will help with bundle sizes in the future.)
I'm not really up-to-date re Clojurescript's package manager, but I know people who've specifically stated that one of the reasons for using Clojurescript is that package management and bundling is just so much easier than the standard JS npm/yarn/bower/gulp/webpack/etc amalgamation.
I would argue that web development have never been as easy as it is now and that a lot of people just does not take it seriously enough to bother to learn it properly. People think that just because that they did some jQuery development 10 years ago they should be able to use to the same skills now and discard all new developments.
Being able to use modern JavaScript and with linting/prettier will in practice make it pretty rare that you end up doing stupid things due to language limitations. And if you want types you have TypeScript that works very well in most work flows.
html/css is pretty ok to work with these days and libraries like React and that echo system makes it pretty easy to scale web development so that many people can be involved in the same code base.
The nice thing about the current situation is, if you want to you can still use jQuery, basic CSS & HTML5 and ECMA sub version 6 for 99% of all sites that exist and are likely to exist. That will remain true for the next decade at least.
Most sites are not applications and never will be. Most businesses will never need a complicated site. Most of the Web has zero beneficial use for React or ECMA 6. Factually that's easily demonstrated just by looking at data compilations of what the Web largely consists of: static content, typically pushed out into the world via a basic CMS. That isn't going to change. Most of what's going on is an evolution in the top tiers, up the value chain. Facebook & Co have dramatically greater technology demands than Joe Small Business or Susan the blogger.
It's just as easy as it always was. Put a script tag pointing to your favorite tool in a blank html page, and get going.
Oh, you mean setting up a state of the art web application? Years ago we had to roll our own pipeline, often building our own bundler and you had to use a ton of separate tools not meant to work together. There was no package manager so we had to download all of the stricts from random websites and hope for the best sticking them in a /vendor folder.
Nowaway you use the CLI of your favorite framework, type 1 command and you have an app all configured for a real world production environment. It's never been easier (and is easier than pretty much any other type of software development).
The only thing that changed is that since its so easy, you are expected to produce a high quality app if you want to be taken seriously. That part is hard.
Now you have a react app with a development up and running. To create a production build write "npm run build". To add a package write "npm install the-package".
> I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered.
It is, but it's getting better because so many different approaches have been tried that some of the more scalable and maintainable ones have been worked out. Also, (thank heavens) browser support is a lot more consistent now.
> I need to build a website soon and I’m dreading the front end.
If you're a software developer, I recommend some atomic/functional CSS toolkit, like Tachyons. That will free you from having to do probably 90% of the CSS work you used to have to do, and it matches a more programmer-type mindset to styling elements.
I'm building a site now, and so far it I've just needed to define some style classes for the colours, and the rest of the styling is already included out of the box via their reusable classes.
For the JS side, really depends what sort of dynamism you're looking for. You can go with a tiny JS library for polyfilling and standardizing browser behaviour [1] if you're just doing simple DOM manipulations, or if you expect to be doing a lot of AJAX with dynamic rendering, go with something like Surplus [2], or Vue, React or Mithril if you want something more standard.
I'm in a similar position, and I've formed the same impression. Furthermore, even though browsers are stuck with JS, given the influx of languages able to compile to JS (or even WebAssembly now) it feels like there should be plenty of options for those of us who would rather stay away from the craziness. Perhaps someone with more frontend experience could comment on what (comparatively) sane, simple and JS-minimizing options are there now?
Compiling-to-JS brings in its own set of crazy, and really almost never is worth it. In fact, the only two that make any sense are Babel and TypeScript, and that is only because are (practically) Javascript and because they are stable and widely used projects. If those two wouldn't hold, you'll quickly be running into a whole host of problems w.r.t. interoperability with the rest of the ecosystem, and you'll end up reinventing the wheel again.
I feel it's the other way around: As long as you're using JS as a compile target, you might as well jump to ClojureScript, Elm, etc instead of settling for a close cousin like Babel or TS.
If you're using ClojureScript/Elm/whatever, there's going to be a lot more hassle to use existing tooling, such as e.g. test runners, syntax highlighters, etc.
There are plenty of tools for ClojureScript, including syntax highlighters and test runners. ClojureScript, like Clojure, also embraces the host platform, and can call out directly to JavaScript, so a lot of existing JS tooling is available as well. For example, the Karma test runner is frequently used.
I’m not familiar with the Elm ecosystem, but I would be surprised if they don’t have pretty good (or likely excellent) tooling as well. I’ve seen syntax highlighted Elm and it’s well known for it’s excellent error messages. Any language change is likely to involve changes in the tools you use, but I don’t think that lack of tooling is a reason to avoid either of these.
Yeah I mean, many compile-to-JS languages have pretty good ecosystems (I know Elm is one, and I believe you that ClojureScript is too), but it's always going to be a pain in the ass at some point. Hell, I've been wrestling with just setting up Jest with TypeScript not that long ago, and measuring code coverage still isn't perfect. You're not going to tell me that you never run into those sort of things with non-JS languages that compile to JS.
WebAssembly is not an attractive compile target for general web apps in the foreseeable future, it's going to remain a C/Rust thing unless it changes dramatically. JS is a vastly more attractive compile target for managed, GC'd languages.
> WebAssembly is not an attractive compile target for general web apps in the foreseeable future, it's going to remain a C/Rust thing unless it changes dramatically.
I use Elm for all my front-end work. Its compiler and debugging tools are really nice. I also like its functional nature. Elm helps eliminate most of the common issues with JS code and I can also accomplish the same thing with a lot less code in Elm. It's probably not for everyone, but I like it.
Modern JavaScript is not a very badly designed programming language. It's a good, productive programming language. Most of the quirks can be disabled with a linter, and optionally a lot safety can be brought in with typing (using e.g. TypeScript).
On the other hand, many developers don't know much about programming and JavaScript, and therefore tend to have unjustified criticism of the language.
JavaScript was a perfect choice for Node.js. It's event-driven design is a perfect fit for a performant web server. Python would have been a bad choice, because it didn't support asynchronous programming when Node.js was created. Furthermore, using the same language in the backend and frontend will reduce context switching, enable code reuse and generally speaking improve implementation efficiency.
modern js is still js. the fact that linters are _required_ to keep code sane is proof enough. typescript is a different language, i'd wager it doesn't count, even though i agree it's a considerable improvement.
au contraire, many developers know exactly what programming in js looks like, especially compared to other languages. i used to think that c++ and boost compilation was crazy. now i look at glorified web pages with 200MB+ of dependencies and wonder how we got there.
i agree that js was a perfect choice for node.js, because it was the only choice for node.js - to use the same language that runs in the client. that doesn't make it a good - or even sane - choice in the greater perspective. python was and still is a good choice - twisted was used to create async services before ajax was a word. you can also take a guess from where the promise/deferred pattern took at least some of its inspiration.
> python was and still is a good choice - twisted was used to create async services before ajax was a word.
Async was not part of the core language when Node.js was first released. Even today the library ecosystem of Python is fragmented, not everything works asynchronously.
>Modern JavaScript is not a very badly designed programming language.
JS fans said the same thing years ago, claimed that it didn't need classes, more extensive core library, or better syntax. Then came ES6, almost a different language, and they magically changed their opinions to match. Apparently all those features they dissed were needed and good. After seeing this kind of switch-a-roo several times I realized that most of JS community have no fucking clue. They will gladly consume and defend absolutely anything they currently consider "theirs" and "modern". It's a matter of fashion and identity rather than language and tooling quality.
JS was and is a horribly designed programming language. The Web would be lightyears ahead of its current sorry state if the core language was a dialect of List of Smalltalk.
It's getting frustrating how much these discussions get dominated by people who self-admittedly haven't used a technology very much and then rant about it. Besides what you brought up, the package manager thing doesn't even make sense.
I'd suggest that inexperience/ignorance isn't a great place to analyze anything from. Some of the "major" issues that dominate these discussions are not problems in practice.
A counterpoint is that people develop Stockholm syndrome over especially broken technology, and immersed long enough will no longer register just how ridiculous some aspects of it are.
It's easy and lazy to assume that you're the enlightened one and everyone else has some defect like Stockholm Syndrome that keeps them from seeing the light.
Other people simply accept different trade-offs than you.
Yea, modern JS... it's just a joke, no integers, still funny effects with []+[] and {}+{} and []+{} and {}+[]. Good luck with writing anything serious using such a crap.
Modern ECMAScript is still stupid, yes. Weak typing is 100% a bad idea, and no new language would take this approach. It has, however, obviously improved to the point where it's actually quite okay to use – a modern ES7 app exploiting features like class sugar, async/await, improved syntax etc. is perfectly serviceable, alongside a linter to prevent the stupid features from old versions biting you.
But a whole bunch of 'serious' applications have obviously been written using JS, and it's a totally stupid view to think otherwise. Frankly the people who are the most concerned with 'my language is better than yours' litigation are by far the least productive developers I've encountered.
Both ESLint and TypeScript solve all that. In all honesty, if you're not using tools like that I'm not sure you're doing "modern JS development". It's like complaining that modern C++ is a mess while refusing to use references and RAII.
In C++, proper tools are part of the language. In JS, they're part of ecosystem of third party components that's changing on a weekly basis. There's a difference.
ESLint was released in 2013. TypeScript in 2012. People keep complaining about this "weekly basis" stuff but really the pace has been pretty slow lately.
If you want to use constexpr in C++ you're going to have to upgrade your compiler as well, right (and, if you're unlucky, "migrate your project files" and all that mess)?
I disagree. While Python, for instance, certainly has its quirks, it doesn't have multiple ways of declaring a function, each with their own scope and hoisting gotchas. In Python, self isn't ambiguous the way this is in JavaScript. Python's datatypes are straight forward, unlike JavaScript, where 1 + "1" produces a valid result. In Python, 9999999999999999 is precisely 9999999999999999, however in JavaScript this is true: 9999999999999999 == 10000000000000000.
I've been a professional Javascript dev for over 5 years and never once run into a bug due to any of these problems.
I agree that they are problems, but their impact on day to day use of the language is zero.
If you want examples of real problems that give good front end devs hell day in and day out, start looking at some of the libraries, tooling and abhorrent "best practices" that get thrown out and cargo culted to death by the community.
I've spent days tracking down a bug around a color picker widget, turns out JS was implicitly casting my string value to octal.
I've worked with heaps of toy languages like Lingo, vbscript and ActionScript, and nothing has made me as viscerally angry as JavaScript (ok maybe PHP's complete lack of naming consistency). JS is an accident of history that has somehow become the de facto standard.
Looks like it's been fixed in ES5. From memory I was performing an operation on a html color string and if you clicked a color with a certain prefix it would crash.
I could easily reproduce the bug but it took me forever to work out why JS was choking. I think I added in some ridiculous string padding to prevent the auto casting.
I enjoy Javascript, have also programmed in it professionally for a little longer than you, didn't read all the docs in depth, don't have a great memory, and it on (admittedly less and less all the time) rare occasions still surprises me with unexpected or downright bizarre behavior. (But I also use other languages and thus know what sanity looks like).
Sure, you can work around JavaScript's warts, but it is one thing to say the warts can be circumvented and quite another to claim that JavaScript is on par with well-designed languages like Python.
I do agree with you that the JavaScript community's issues you mentioned are hell to deal with; however, in my opinion, JavaScript's internal weaknesses are one of the driving factors behind this churn.
> re: it doesn't have multiple ways of declaring a function...
Python does have multiple ways of declaring a function, the usual `def` syntax and via `lambda`. Lambdas are restricted to one line (due to Python's whitespace sensitivity), which can be inconvenient (but hey at least no one can abuse it right?).
Python functions also have a scoping gotcha: you can read the variables in the outer scope, but if you write to it (without declaring it as nonlocal) it actually treats that as a separate variable declaration (this is due to its assignment syntax).
> re: Python's datatypes are straight forward...
While Python's type system is nowhere as lenient as JavaScript's, there is at least one unexpected case which works: `True + 1` produces as valid result (2). Also, having to explicitly cast non-strings is rather inconvenient when concatenating stuff to produce a string (even Java doesn't require this). Thankfully, Python has a decent string formatting function built-in.
> re: 9999999999999999 is precisely 9999999999999999
It'll still fail if those are floating points. Yes, I am aware that Python has decimal and rational types in its standard library. My point is, no matter what language it is, programmers need to be aware of the data types and data structures they are dealing with.
FWIW, I don't think JS is better (or worse) than Python (as long as we're talking about "modern" JS with modules). Python also has its fair share of major issues, notably v2 vs v3, which is slowly becoming a non-issue as everyone (finally!) migrates to 3.
Just because JS' _this_ doesn't behave like in other languages doesn't make it bad, I mean it's behaviour is well defined.
JavaScript is more dynamic than most languages and yes this may be hard to grasp for the average developer, especially when they come from languages that are considered "more mature".
Yet we still struggle with making sure we've got all of the tools that could check the mistakes I have accidentally made before I had shipped the code.
XMPP had been defined as formally: where have we ended up with it now?
Python has at least 4 ways to define a function: you can have a plain function, a bound instance method, a bound class method, and a lambda, which is similar to the same options js has.
Python's type handling is much better, but that can be mostly avoided in JS by understanding and avoiding the cases where js typing sucks.
Other than Python's superior type handling and standard library they seem like very similar languages to me.
Both ESLint and TypeScript solve all of that except the integer thing.
But I'd wager that the "no integers over 2^53" is seldomly a problem, and in most other languages there's a similar problem at 2^64. If you reasonably expect to get integers above 2^53, you probably want to think about how to deal with integers above 2^64 as well. So really it's the exact same thing except JavaScript's numbers are easier to complain about on the internet.
Actually, in Python integers have no upper limit (sic!).
I did some Ethereum front- and backend development in both Python and in JS, and this made a lot of difference in the readability of the code. In Python, the only problems we encountered was when writing into ndb, which has 64 ints by default, whereas in JS, we had to use BigNumbers everywhere.
Oh wow, really? I feel pretty stupid now. All languages I've used in anger have an upper limit for integers so I'd just assumed this was pretty much general. I see now that it works in Ruby just like in Python.
It's a bit annoying when doing interop between languages that have the (more common) 2⁶⁴ limit and JS - int64 for IDs etc is fairly common and you then always have to remember to convert them, e.g. by putting IDs as strings in JSON output instead of as a number.
I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered. JavaScript is a very badly designed programming language
Let's take a step back here: the web is designed, from the ground up, for hypertext, interlinked documents comprising text and images, some of which are clickable and lead to other hyper-documents. HTTP - hypertext transfer protocol. "Web dev" should be referring 100% to things that happen on the server, which can be in any language you like, generating documents that are rendered as the end user would like. Forcing a thing designed for documents to run entire applications is what has gone wrong, it is, on the most fundamental level, an incredibly stupid thing to even try, but the entire industry did, and here we are today. It would be like MS declaring all Windows development henceforth will be in VBA macros for Word.
This is why the real engineering disciplines don't take software engineers seriously. You would never see a civil engineer try and construct a bridge out of some completely inappropriate material...
Thank god for speaking up about this. This whole thread has me contemplating a career change. I'd rather dig a hole and fill it back in. The OP is pondering what framework to use for the front end. How about you do the design/css/copy then worry about the framework.
I think the main problem is everyone insists on over engineering a fucking website.
it may be, on a fundamental level, an incredibly stupid thing to even try, but it also seems to have been an incredibly necessary thing and incredibly appreciated thing by most of the world.
Necessary how? All the actually useful things you can do on the web you could have done with a 90s browser. I bet Amazon still works in one!
Moving apps into browsers is a step backwards for most apps and most users. I was using Jupyter the other day; it’s clunky as hell compared to MathCAD from 20 years ago. We use 1000x the computing power, literally, to deliver 10% of the experience. Keeps a lot of devs employed I guess...
You're pre-emptively trying to define what's useful for everybody else. That's the only way your premise works.
In my equally subjective view, XMLHttpRequest radically altered and improved the useful things you can do with the Web.
You can't use a 90s browser for Google Maps, Gmail, YouTube, nearly any online productivity software, and dozens of other common activities on the Web today. You would have to strip the services down to make them work, ie turn them into completely different products.
Simply put, most of the things most people do online today, can't function in a 90s browser. Just try using IE 5 or Netscape 4 with nearly any of the major Web services today. You can't. IE 5 with Facebook's non-mobile site? You have to build an entirely different product to make that work, basic interactivity drops to near zero.
1990s MapQuest sucked, big time. Google Maps is a radical improvement. How about simple things, such as smooth, fast, highly interactive stock charts, or real-time updating stock quotes, without having to reload the page constantly? 1998 browser? Nope.
Would the user experience be better if everything on the Web adhered to strict 1998 standards? That's an obviously subjective opinion. I don't think so. Do people like to see instant previews of the content they're about to post to Facebook or Twitter? When they click the little upvote arrow, do they like to see an appropriate reaction? When posting basic content or interacting with simple site features, do they like having to reload the entire page?
All those things existed before they became web sites, and they aren’t web sites for any particularly good reason today. Email is a good example. GMail is Outlook rewritten in VBA running inside Word.
Let me guess... you’re a JS dev and you think “little upvote arrows” are where the real value is?
Except for the fact that most people use these services in the browser even when there are native clients available? In nearly all of the listed cases the bottleneck is almost always the network and not the JS runtime.
Clearly the users are wrong, I guess? Perhaps you should explain to them why your delicate design sensibilities dictate that they should download native clients because you think HTTP has gone off spec.
Let me guess... you're a COBOL dev and think computers should have never developer GUIs.
you're a COBOL dev and think computers should have never developer GUI
Not quite that old, but I was doing web and Java professionally in 1995, so I’ve seen it all.
The users are not wrong; they’ve simply been trapped in a local minima by inexperienced developers who would rather reinvent the wheel than make progress. Except every time the wheel gets squarer.
Gmail is Outlook rewritten in VBA running inside Word, except it works better and doesn't leave you open to a bunch of viruses. I mean did you ever use the Windows client of Outlook? On the one hand your argument makes it seem that you did, but on the other hand you also seem to prefer it to Gmail which makes me distrust the argument completely!
Then you could add a single css file in which you prefix class names using something like: myprojectuniquename__someelement.
Then if you use async/await instead of callbacks, flexbox in your css, check supported browser features by googling 'caniuse feature', and use fetch for network access, you could have a pretty simple system that works for you in under an hour.
You say that like it's always a good thing. I remember I spent 4 hours trying to import a function from a file that was in a sibling directory before I finally gave up and copy pasted the function.
There's also other things that really rub me the wrong way in Python. Once you get used to writing computations as a map/reduce/filter pipeline with fat-arrow functions in ES7, Python lambdas and list comprehensions feel so crippled and lacking in comparison.
There's a lot of other things that ES7 does really well such as imports, asynchronous code with promises/async-await, array/object destructuring, the spread operator, etc.
Don't get me wrong; I love Python and use it heavily in my day job, but it's not the end all and be all. There are fantastic libraries written for Python that make life really good (think Reportlab), but for applications that are highly asynchronous and I/O heavy, I'd take ES6 running on Node any day over Python.
I feel like everyone is picking up on your language complaint, but maybe that is not your biggest concern.
It seems like you give JavaScript as an example, but what really worries you is the complexity of the front end ecosystem.
Here are a few ideas to reduce that complexity:
Don't use a package manager, you can copy dependencies into folders.
Remove steps from your build pipeline unless you really need them. Use ES16 to get native promises and imports. Or don't use ES16, so you can remove that step from your build pipeline.
Use as few dependencies as possible. Whenever you can, make use of native browser behavior and CSS.
Less automation may help reduce his complexity, but will lead to more instances of breaking things do to mistakes due to manually performed steps. In general, I agree with part of your point - only use what you need. But make sure you are using the things you should.
I read all of this, made a 8 paragraph long retort about the stupidity of backend devs in this thread, then deleted it.
The reality is, if you don't currently serve a website 1,000,000 people want to use, just pick some terrible server side piece of crap and call it good.
If you want 1,000,000+ people to use your website, you better learn that a dynamic user experience is expected, and delivered with eloquent javascript and design.
> There appear to be an excessive number of package managers involved.
Largely agree with your assessment except for this. Which package managers are you referring to? 99% of the js world uses npm, and the other 1% uses yarn. I’m not aware of a single other package manager in the web ecosystem. In fact this is probably one thing where they got it right.
I find it kinda funny that you compare to Python as the way you want webdev to be, since Python and JS are very similar in my mind, aside from minor syntax differences and JS keeping more warts from it's early days, they are very similar environments.
I like Python and have been doing some Tensorflow recently, and one thing I've definitely noticed is that Python docs really suck compared to mdn JS docs.
The biggest problem with JS on the other hand, is it's lack of a decent standard library so you have to use a lot more 3rd party libs, and setting up a modern babel/webpack/linter/test tool chain is a pain in the ass with so many different options to choose from.
Javascript WAS terribly designed but still allowed su to do amazing things. I would argue that in the last 3 years its come a long way and is no longer a terrible language.
I think complications of today came from the problems of its past where it was taken for granted that you needed a framework to get around browser differences.
My personal and professional view has been use plain vanilla modern JS. Make an informed decision on whether using a framework makes sense for your particular project.
If you're making a mess of JS, its more likley you need to re-evaluate your approach to the problem rather than the easy thing to do which is to blame the language.
>> If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend
Low-code tools are worth a look, depending on your task. Due to some reason, they are rarely mentioned at HN, But they already work very well for business apps, with some tools even claiming "pixel-perfect" ui creation, so maybe it can work well for consumer apps too.
And Amazon/Microsoft and Maybe Google are all working/having on such tools, so it may indicate these tools are becoming popular.
I know when someone comes from C family language, he/she is not able to understand JS first but the person who knows JavaScript programming will never write like this. Actually JavaScript has few concepts those are much different compare to C family language like prototype and pure function which are superb. Even C family languages developer are now thinking to add few concepts from JS language.
JS isn’t really terrible, I’ve done 25 years of c, c++, go, pascal, swift and I found js lack of typing refreshing. I built a fairly complex app in 4000 LOC. This would surely have been 10x bigger in any of the languages mentioned above. If you use es6, you get rid of the most common js issues (var hoisting, this scoping, etc)
At some point 10x less LOC has to be factored in as a significant benefit
For website you don't need any libraries. You might consider some static site generator.
For SPA go with create-react-app with react router with TypeScript and MobX and you will be satisfied. If you don't need/want to configure things swap webpack for parceljs.
can your web site be pre-rendered or rendered on the fly? then do server side rendering - only send html to the client. if you need dynamic rendering - use static js - only for those parts. if you need everything to be dynamic rendered eg live push, multiplayer games etc do full js rendering but do not use static html! only css/js. i think the complexity comes from web devs familiar with server rendering tries to use the same paradigm with dynamic sites for example angular and react. you should do it more like a desktop app instead of web page. if it makes sense do the rendering in canvas instead of the dom.
You said it. You're not an expert. You are comparing a prototype based language to oop languages. You're basically putting the wrong fuel in a car and blaming the car. You are lazy in my opinion because yes there are few resources that teach you how to use the language properly but plenty that compensate for those who want to make it familiar to back end devs. If you looked for good resources you will slowly discover that most JavaScript developers do not understand the language well because of the same assumptions you are making. It's a highly misunderstood language due to human stupidity.
While it is certainly possible to understand JS it is - IMO - a waste of brain cycles that we have to live with. There's no doubth in me that even very good Javascript programmers can be significantly better in a better language.
E.g. Typescript gives you literally all of JS - and a way to keep things tidy.
Typescript which is a compile-to-js language in a weird way proves how lacking js is - while still buildiing on top of it.
"very good Javascript programmers can be significantly better in a better language."
This is not how it works.
Take this idea that JavaScript is a "badly designed language" out of your head and understand that about 99% of JavaScript's behaviours are intentional.
The majority of gotchas in JS are shown by people who don't understand type coercion, prototypes or who expect it to behave like x language.
It is not just misunderstood by your average Joe JS dev, but also by many who claim to be pros and experts.
JavaScript is a language that doesn't tell you how to do things, there are no constraints. This is why so many people suck at it.
They want to use statically typed classical inheritance constraints on a language oriented around higher-order functions, coercion and literally everything being an object.
If you are somebody who is intuitive enough to create your own restrictions on what to use and what not to use in JS from the POV of the language's architecture then you will love it.
If you are convinced that there is already a holy grail structure to programming languages then you will always have problems with JS.
TypeScript is miserable. I see people building libraries in TypeScript and it's sad because they will never know how much better their performance could be or how small their lib size could be because the can only think in OOP.
OOP languages are already hugely problematic when it comes to complexities. So imagine how overly complex the JavaScript eco system is becoming due to a generation of developers who want it to be more like x OOP language it does not have the foundation to be like.
There is no defacto solution for software engineering everything still sucks, and nobody remotely has it figured out.
> Take this idea that JavaScript is a "badly designed language" out of your head
Respectfully, no. The impressive thing about it is it was written in 3 weeks. Edit: I also didn't say Javascript was a badly designed language, at least not in the post you replied to.
The rest of it is like PHP (yes, I have programmed a fair bit in that as well).
> and understand that about 99% of JavaScript's behaviours are intentional.
So much worse ;-) There is one good defense for Javascript IMO and that is it was made in a very short time.
Intentionally leaving in a heap of footguns like Javascripts type coercion isn't brilliant, it is either pragmatic, myopic or evil. I say pragmatic in this case.
> The majority of gotchas in JS are shown by people who don't understand type coercion, prototypes or who expect it to behave like x language.
The classic Perl defense I'd say: ~you don’t understand the beauty of it.
> TypeScript is miserable. I see people building libraries in TypeScript and it's sad because they will never know how much better their performance could be or how small their lib size could be because the can only think in OOP.
Well, every thing you can do in JS you can also do in TS.
In a sense you can say this is our implementation of what you said above: "If you are somebody who is intuitive enough to create your own restrictions on what to use and what not to use in JS from the POV of the language's architecture then you will love it." And here you are right: Typescript is quite a lovely language:-)
Also: By this logic we should be programming in assembly.
Actually 10 days, with 22 years of development, but that has nothing to do with how it fundamentally works.
> The rest of it is like PHP
Are you joking? Ok so, JavaScript is a prototype based language PHP is (now) an OOP language. They are not remotely the same with the exception of dynamic types and even that is nothing like PHP due to the nature of JS engines like V8. But because if the prototype system it can emulate classical OOP.
JavaScript is also a higher-order language which mean it is a psuedo-functional programming language.
PHP and JS could not be further apart.
> The classic Perl defense I'd say: ~you don’t understand the beauty of it.
It's not about beauty, I'm saying that most people who think the language is making mistakes or doing something wrong just don't understand how it works. They blame it for their lack of knowledge.
> Well, every thing you can do in JS you can also do in TS.
But that's not why people use TypeScript, they use it to do TypeScript styled things.
> what you said above: ~ intuitive enough to create your own restrictions
That's the problem, TypeScript comes with a bunch of constraints, that's its purpose. Yes you can choose to use them or not. You could also buy a new phone and throw it off a cliff, but that's not generally why people buy phones.
> Also: By this logic we should be programming in assembly.
Assembly serves a purpose well, so does JavaScript. I'm just saying rather than trash things why not learn them first properly.
> TypeScript is miserable. I see people building libraries in TypeScript and it's sad because they will never know how much better their performance could be or how small their lib size could be because the can only think in OOP.
And once that lib gets larger then 4 files, it becomes slower and slower to maintain, because JS. Spinning up new devs on any large JS project is a pain. Typescript, no problems.
I programmed in more than 10 languages and I'm very productive with TypeScript and I doubt there's better language for interface development or I would be using it instead.
A programming language is not supposed to match human intuitions. We are trying to take things from the physical world an represent them in the digital world.
A programming language should be modelled on physical life.
But we still haven't figured this out yet.
I don't think many people understand what a poor language is, you really need to understand the spec fully and experiment with every paradigm in production to claim that JS is a poor language. Can you genuinely say that you have?
> A programming language is not supposed to match human intuitions.
I'd say that's a flat out false conjecture. Given a choice between two programming languages, one which better matches our intuitions and one which doesn't, the one which does will always yield programs with fewer bugs because we will simply be better able to express our solution to the problem being solved, and we will be better able to understand the program and so extend it.
It's like saying that door knobs are not supposed to match human intuitions, they're just supposed to open doors in the best manner possible. Well guess what property opens doors in the best manner possible when humans are the ones opening doors? A door knob that's most intuitive and natural for the majority of humans to use. HCI and ergonomic factors are seriously underappreciated in computer science.
> you really need to understand the spec fully and experiment with every paradigm in production to claim that JS is a poor language. Can you genuinely say that you have?
I've used OO, FP, prototype-based, logic and constraint-based programming languages. Yep, I think I can say JS is not a good language. It's improved somewhat, but still not great. It's not Brainfuck-bad, but it's not particularly good either.
> A door knob that's most intuitive and natural for the majority of humans to use.
Ok so let me explain better:
The UX = Human End-users POV (intuition)
Programming syntax = Human Developers (intuition or whatevr)
Tools to deliver (Browser API, CSS) = The domain/s
The way in which we structure work = the things we are building = things that exist in real life.
Websites are mis-leading because many pages appear alike people tend to believe that there's a lot of repetitive components but there really isn't in general.
So inheritance is usually way over used despite the style of programming.
I am not discussing how we use a door knob. I'm arguing about how we build the door knob of different variants in mass production.
> It's not Brainfuck-bad
Brainfuck is not a "bad" language, if it serves it's purpose well then it is good. I think Brainfuck is doing exactly what it intended to do.
There are people who have been using JS for 20 years who think it is terrible. It's because they have never taken time out to learn the language properly. Most JS devs don't
I'm not convinced that you have because you clearly wouldn't be saying x is a poor language. No language that is in high demand today is a poor language.
> No language that is in high demand today is a poor language.
Well that's clearly false. COBOL was in high demand at one point. The popularity or prevalence of a programming language has very little to do with its technical merits. We've seen this play out dozens of times over the past few decades.
And "X is bad" is typically intended as a relative measure. JavaScript would have been a great general purpose language compared to the state of the art in the 50s and 60s, maybe even as late as the 70s. It was maybe ok as an embedded document language at the start of the web in the mid 90s, since everything was so experimental and quickly evolving. It's not a good language now, and hasn't been for some time. It has some good qualities, but also many bad qualities that run into bad software engineering practices.
Finally, I'd say that any language that many people would rather use a transpilation/compilation target rather than use directly, is clearly a bad language.
The root of the "problem" is that the web is an unusual platform. It actually punishes bloat, in a way other platforms don't. A native app can use a hundred libraries and a gigabyte of download size to do something trivial, but on the web that won't fly. That means web developers must learn that code reuse is a tradeoff instead of seeing it as a pure positive. That's a good thing in my book. Either take the heat and replace your 10 dependencies with 1000 custom-written lines, which is usually easy in JS, or get out of the kitchen.
TLDR;
The language design of JavaScript is not the problem. There are 2 problems in my opinion:
1. Our reliance on typed languages, compile-time errors, and IDEs
2. Too many choices for frameworks and libraries.
I wouldn't agree that JS is a poorly designed language. I will come back to that soon.
I would argue, like some others here that we are just too lazy. We enjoy the safety provided by typed languages and compile-time errors. That is one reason to love our IDEs.
Back to the problem. There are a lot of things that you are saying. I will try and address them one at a time.
> web dev has been badly engineered.
* Yes, no, and it depends. Web Dev is a very board, it encompasses many technologies, like HTTP, HTML, CSS, JS, Application servers, etc. So you are saying HTTP id bad? or HTML is bad? I know I'm reading it out of context, but bear with me. I believe you meant JS is bad. That brings us to your next opinion.
> JavaScript is a very badly designed programming language.
* When you say badly designed language, what is it that you exactly mean? Is it the syntax? Is it the grammar? Or is it the fact that it is loosely typed dynamic interpreted language? And what are the problems you talk of, any examples?
> Is JS a recognized terribly designed language?
* Who recognized it, any sources? Like the U.S.A. recognizes ISIS as a terrorist organization. I'm pretty sure the developers of node.js do not recognize that JS is a terribly designed language.
> There are many frameworks for the same tasks, that try to do everything.
* Yeah, I agree. I really hate having so many choices. I have to spend too much time investigating which is the best one for my use-case. I'm just too lazy. (sarcasm was intended) That said, I still agree, and it does make life hard. But too many choices is not a bad thing necessarily.
> There "appears" to be an excessive number of package managers.
* There is only NPM, everything else is either deprecated or based on NPM. Please inform yourself better.
> ... range of solid and well-designed languages and technologies, but at the front end ... choose the least poor of a bunch of crazy options.
* WHAT? There is only 1 option on the web today; JavaScript. Period. Unlike backend. What you are talking about are framework and libraries. Check the "too many choices" point above. If you believe that backend development has fewer choices involved, then I assume that you sir have limited experience.
Anyway only recently has the community invested in improving this. Give it time, unless you believe something else can replace it before that.
>JavaScript is a very badly designed programming language (yes, even in its modern form), which I think has caused a lot of problems. Many JS developers don’t know much about programming language design, so they can’t see how bad it is, and they make matters worse by not trying to abstract or use JS in a way that reinforces good PL design methods.
I attribute much of this to the cargo culture that always dominated the webdev space. I lost count to how many seasoned devs (5+ year) I met who were telling me that "Framework A" is faster than vanilla JS and DOM with which they were built with, or array methods are for some reason faster than loops without function calls.
Another weak side of JS today is it being driven by "design by committee" and attempts to treat the patient by measuring the average body temperature of all patients in a hospital.
I put to doubt the level of basic CS proficiency of most JS framework authors. Some times they try to appear smarter than they are.
Web apps are broken and always have been. The whole model was designed to serve and display static hyperlinked documents, not to recreate Excel in a browser.
The lure of web apps was serving them from a centrally controlled location thus eliminating the problems that existed with pushing out and updating software on many computers.
However, that problem was solved many years ago and I point to iTunes as that inflexion point. It's been easy to push updates to desktop clients for years so the main problem web apps were attempting to solve hasn't been a problem for, like, 15 years.
The ultimate irony... The phone app eco-system and how it dwarfs mobile web apps.
> Directness is best in my experience, so a great photo, memorable illustration, or pitch-perfect sentence does most of the work. Beyond that, fancy implementation has never moved the needle much for my clients.
> Last month, I had to install a package manager to install a package manager.
...
I sure as hell know about spaghetti workflows and spaghetti toolchains. It feels like we’re there now on the web.
If I wanted to install pip, I'd install virtualenv. (I'd use apt to install virtualenv, sure, but using apt to install pip will eventually turn out to be a mistake.)
When I worked in embedded systems and systems programming a decade ago, it was totally normal to spend over a day getting your computer set up after joining a new team.
Sounds exactly like what the author describes here, so what changed? What changed is that the browser became a popular application platform, forcing frontenders to deal with the stuff everybody else has been doing for decades.
I'm not saying this can't be improved, and there's a huge difference between projects in that respect. I know teams where getting up and running is a matter of installing node, yarn, and running a "yarn install" and It Just Works.
But the thing is, build tooling is hard and it always has been. This has little to do with web design, except that designers used to have the comfort to be able to ignore it. And that's harder with single-page web apps.
He’s exaggerating. You can download a cli tool that lets you create a react or vue web app with Babel, webpack, hot code loading, etc in one command. It just works. I know because I just did it and built a large app from it . I think I added 3 lines to my webpack config to proxy api calls to me real web server. It’s magical to code on the fly and I think people have a short memory or aren’t old enough to remember hand coding make files and waiting 20 minutes for your app to compile and link.
Frameworks like vue.js are elegant as all hell and js has the lowest getting shit done to ceremony ratio of any language I’ve ever used.
Sure there’s a few gotchas. Try using c++. Now there’s a minefield.
Not sure if this is about comfort. Those complicated workflows and interfaces pretty much go against the principles of what designers are trying to achieve with their own work.
I've almost never touched web development, but as an active HN reader I have at least passing familiarity with almost all the terms used in the article.
So, honest question: can a person fully understand how modern HTML/CSS work without diving in the source code of one of the browser engines? Because as a developer, if I was forced to use such a complicated technology, grooming source would be my best guess at making any sense out of it.
Yes. Read the whatwg HTML spec for developers [0].
Understanding ALL of CSS is tricky, because it has a long history. It's also incredibly tricky to understand how it all works together when different display modes are combined. But you don't need to understand ALL the parts in order to build something useful. Just skip over the parts you won't be using.
Do you think any of the alternatives are truly much better?
No dive necessary if you don't get close to performance limits of browsers. Actually looking at how it's meant to be first is the only sane way, because browsers do whatever the fuck they want and you just have to see what happens.
I suspect your parent comment isn't talking about browser compatibility. I suspect it is about learning enough CSS/HTML to write up a page for one browser without feeling like [venetian blind gif].
http://book.mixu.net/css/ is a reasonable guide and as a backend dev, I've learned to feel more comfortable with HTML/CSS by reading through it multiple times and making flashcards in a Spaced Repetition app.
I have found lately that many web things today are based on fads and they have found their way into the standards. In the past, standards were developed through engineering and computer science. Today it's based on fireworks, explosions and emojis. Speed trumps quality. Do not want to think is the motto or slogan.
If there is a framework or library I can use then, great, I don't have to know how it works so I won't bother seems to be the mantra today. Which, in my mind, reminds me of "All in the Family" scene where Gloria is talking to her friend. "Daddy said girls don't have sex, only boys do." Friend: "Then who do the boys have sex with?" Meaning, if no one is doing the thinking, who is going to write the code?
Not a fad but an example of what I mean (and the only one I can think of this early in the morning). "box-sizing". This seems to have been created because people are unwilling or unable to understand the standard "box model". People find box-sizing is easier for them but it is not necessary as it only combines already available and well understood sizing properties.
Worse, many even use the '*' hack to apply it to every element on their site which should make one question forcing browsers to do something browsers don't do natively.
iirc, there was, or is, even an effort to make emojis part of the standard!
I hesitate to give any example at all because every person who doesn't know the box model will downvote my post for the very reason I gave in my original post.
Box-sizing is not a good example of a standard that was poorly engineered: it actually fixes a poorly engineered standard instead.
I understand the box model, which is precisely why I think one should not have to perform mental padding calculations just to know how wide an element will be on screen. Content box sizing (the original standard) also makes CSS less composable (since the results of combining multiple classes are harder to account for). Ergonomics are a very important engineering consideration.
The <!DOCTYPE html> tag also forces the browser to "do something it doesn't do natively" (enter standards mode) so does "use strict"; these are concessions one has to make when a platform evolves over 25 years and must remain backwards compatible.
>one should not have to perform mental padding calculations just to know how wide an element will be on screen
This, and the paragraph, falls directly into my comment about not wanting to think or do the work.
>The <!DOCTYPE html> tag also forces the browser to "do something it doesn't do natively" (enter standards mode)
Bad example. Using a doctype was not originally required and was only forced into being by Microsoft not following the standard. Technically, one does not need a doctype at all but we were forced into using it so browsers know you want to be in "standards mode" and not "quirks", but this diverts from the topic.
My "poor engineering" remark was a response to your original comment stating that "In the past, standards were developed through engineering and computer science."
Re: "not wanting to think or do the work": why would anyone want to think more or do extra work that is not required, except perhaps for fun? Computers were created precisely to automate and abstract away mundane tasks (such as adding padding measurements mentally). Only at Google/Facebook scales the extra bytes/CPU cycles added by setting box-sizing for all elements might perhaps make a difference. For everyone else the maintenance, time benefits of reducing the mental overhead imply on actual reduced costs, since you can ship your page/app faster.
My remark was in regard to my first statement about standards following fads but that does not mean the standard is poorly engineered.
My main point, again, falls back to people wanting things done for them because they don't take the time to learn how things works. They want things done for them and never learn the basics, the foundation of understanding. If one cannot figure out how to make an element a certain width using "width" + padding + border + margin because they never bothered to read the specification, or any of the multitude of online tutorials, where it is clearly explained that width is the containment area alone, then this is nothing more than plain laziness mixed with "give me teh codez".
I've recently realised that most of modern day's web stem from the fact that it's not a platform. It's still just a barely functioning system to display text documents.
That's where all the complexity comes from: people are trying to build/collect the missing pieces of a platform, and then try to build their stuff on top of it.
And you can see it everywhere: from CSS (which still pretends that modularity doesn't exist or that complex constraints in layouts do not exist) to DOM (which hasn't seen a proper API design in years) to Javascript (whose idea of a standard library is adding an underspecified `fetch` after 15 years of people writing wrappers around XMLHttpRequest).
The whole thing is driven by all fields reaching the highest level of complexity their practitioners can understand.
Web design in not inherently complex, but it is filled with lots of talented and intelligent people because the pay is good and the conditions cushy compared to say gutting chickens in some factory. The only way to solve to the complexity treadmill is to drive out all the smart people.
No it's not. You decided to make "easy" tasks complicated. Then rather than learning about new technology you wrote a blog moaning about it. Just stick the basics if that's what you want to do. No need for loaders or preprocessors if you don't want to use them.
I love the way that the the author, skirts totally over Javascript, and yet the threads here are full of mild skirmishing.
The closing paragraph is the nicest part of the article, mentioning the benefits of legibility.
I never disliked the mechanics of html table based layouts, col and row spans, what wasn't so nice was the attribute soup. That made reading the outlines of the html hard.
Back in the day we had tools like Dreamweaver, that had a visual design mode. It was quirky so people resorted to programming html in text editors. What's a real shame is that there wasn't a tool that matured to the point, where you could do a little of both.
The most interesting part about a website for me, is usually the content, and the rest is pretty much guff. The nicest thing about simple authoring is that it allows the on-boarding of everyone. Not just arty or programming types. This is why Facebook in part took off. Because it made publishing easy. Weeks, months and even years of development just to get to the point of publishing is rather wasteful. Many sites could simply use a template product.
Review the end result. Many web sites still just look not much more than, erm, web sites. And many don't work, or even convey or make the information that you simply want to consume easy to find and digest.
Loads of technology is thrown at problem, where a simple site map and text based content will suffice. And if a business isn't reactive to customer requests, or doesn't update relevant content - then a site becomes quite superfluous or even a liability.
It's not hard to make websites, it hard to make fashionable websites. It always takes effort to be fashionable, since it distinguishes your vitality from the dead and dying from yesteryear.
If it was easy to fake fashion, everyone would do it, and we'd lose the vitality signal. Fashion changes unpredictably, so it can't be anticipated. All this is a feature, not a bug, so it will never be "solved".
As a back-end developer, I started off coding ~15 years ago, and hated the entire experience back then. Nowadays, as I look at the tools, frameworks and language enhancements, I'm so glad to be coding in 2018, and not in 2004. The things I can easily accomplish now, far exceed anything I could have done back then.
I've heard so many front-end developers/designers say the opposite about their field though, and I wonder why that is. If the newer tools/frameworks are just adding more complexity, or reinventing the wheel, couldn't you just choose not to use them? I suppose some might reply that you're forced to use these new tools/frameworks, because of dependencies on other tools/frameworks that you actually care about. But if that's really the case, and if this frustration is widespread enough, wouldn't people/companies have invested time and effort into supporting the classic-but-equally-good tooling?
As someone watching from the outside, I can't imagine a world where an entire industry is running in circles, creating churn devoid of positive value. Maybe I'm too optimistic, but I suspect that many of the complainers are suffering from rose-colored glasses. As a heavy web-user, I've noticed that the functionality and aesthetics of websites have improved dramatically in the past 1-2 decades. The websites I see from the 90s and early 2000s, look like a joke today. I suspect that this improvement is only made possible by the new tooling and frameworks that exist today. That they are indeed more complex, but they still unlock new potential that would be too hard to achieve otherwise. That anyone who tries to use ancient tooling from 10-20 years ago, would find themselves unable to provide an equally good mass-market UX. If this is not the case, I invite someone to prove me wrong.
When I'm thinking about bloated web frameworks and inefficient libraries, I often come back to memories of 64k demos released by groups such as Farbrausch. Here's what they've pulled off in 2000: https://www.youtube.com/watch?v=Y3n3c_8Nn2Y - as somewhat of a "contrast", jQuery alone (3.0.0-alpha1, minified) weighs 84522 bytes.
Use (what you deem as) the right tool for the job. As to how we've got to where we are today, there are lots of reasons - but personally, I feel it's pointless to constantly talk about it. Whether things are more complex than they used to be is up for debate, it's entirely subjective.
It's natural for things to evolve given the rising popularity and increased demands - but they evolve organically. People flock to frameworks because there's abstraction, and the "dirty work" has been offloaded to a third-party. This saves people time and effort. It's a bet - frameworks come and go, maintainers disappear; that's just the nature of it.
"How do I put two things next to each other?" - Just stick with flexbox. It's way easier than floats. If the older methods are easier, just keep using them no problem.
"Webfonts?" - 10 years ago we were using "swfir" (flash) for custom fonts. Way harder than font-face. Loading fonts with @font-face doesn't need to be complicated: just serve the woff file and be done with it. There are some optimizations that can be done to make them load faster, but they're not always worth it.
SVGs are really nice because you don't need to deal with any resizing. A huge win.
Yes, raster images are a little harder because of high-dpi screens. Just send 2x resolution everywhere. Phones are where bandwidth really matters, and they're mostly high-dpi anyway. A 3x dpi phone getting a 2x image is still pretty good. Any of the more complicated solutions are just to make things slightly faster in some cases, which is often not worth it.
I don't get all the ranting. I think the author would be better doing a research about the current technologies for doing websites (as opposed to web apps).
For websites I can recommend Bulma, it's an elegant base for modern websites. If you want to manage content for that website you can integrate Hugo an get into the world of static site generators.
If you really want to do anything more complex, there is Vue.js.
You can still use <table>s for layout if you want, there is nothing forcing you to use CSS Grid. But if you do learn it, you'll be able to produce more complex layouts with a little less effort.
Innovation often has casualities and the pace of innovation of the front end particularly has exploded in the last few years combine that with mobile uptake and we have a whole can of soup on our hands. At the moment it feels like we havent quite settled on a proposed standard of build tools and processes which comes across as daunting but imo is also indicative of not reaching the absolute peak. Underneath it all we still have the fundamentals of html css and js and that aint gonna change anytime soon.. I only hope some of the tools we have for layouts settle soon as the browser landscape and chasms are only getting wider as mobile devices and iot throws a whole new can of worms at producing cross browser compatible applications. In my instances that fact alone is choking the web.
Much of the JavaScript ecosystem can be cringeworthy, but recent versions of JavaScript are far better than the days of ES3, and libraries like Babel are high-quality.
With modern improvements to XMLHttpRequest, the URL object, and JSX (actually quite easy to use without React), I suspect that creating a fast, modern website using only Babel, Yarn, and a few polyfills (mainly for IE) is quite easy and enjoyable. Of course, if you want a styled date field, autocomplete field, etc., you'll want to use a library, which may have its own dependencies.
As for CSS, everyone agrees that flexbox is a godsend.
you still can write `<html><body><h1>hello world</h1></body></html>`, there is nothing wrong with it!
but once you have written a file-browser with an embedded editor in it or anything else at more complex level, you will consider using react and all the things. because complex things are complex.
again, for simple things you can easily use simple tools - maybe you should. but of course once you are using react day in day out because you need it for other things - you might just use it for anything because you are familiar with it.
"If you go talk to a senior software developer, you’ll probably hear them complain about spaghetti code. This is when code is overwrought, unorganized, opaque, and snarled with dependencies. I perked up when I heard the term used for the first time, because, while I can’t identify spaghetti code as a designer, I sure as hell know about spaghetti workflows and spaghetti toolchains. It feels like we’re there now on the web."
It’s rare that I say someone has truly nailed it, but the author has really nailed it. And while much of the critical response has focused on the difference between design and programming, I can say as someone who has been around the programming block (got started at age 9) that 99% of what he says applies equally well to modern application development and infrastructure.
It's lazy loading the images - when the page initially loads, it only loads one small image (trans.gif), and the file specified in the data-src attribute isn't loaded until you scroll near to the img tag. Specifically, it's using this plugin: http://luis-almeida.github.io/unveil/
Given the topic of the post (the need to keep things simple when making web pages), I consider these observations relevant.
1) Probably as I'm not in the business and I don't follow most recent developments so I don't know if the arguments from computerhope.com are obsolete by the most recent standards or implementations, so all relevant technical information is welcome.
Tracking scripts don't need to do anything but read the hit in the access log. That said, it's also trivially easy to output the bytes for a 1x1 invisible gif as the response from your tracking endpoint.
It is easy, but is it fast? Serving a static GIF has an overhead of ~0, and it doesn't need any executable beyond the HTTP server to run on the machine, except to move the logs out for processing (syslog, rsync, what-have-you, in most cases out-of-band wrt the HTTP server).
Well written and beautifully presented but these are complaints about progress.
> 'my limited needs...Simple, responsive layout'
As we all know, limited/simple in the requirements doesn't mean simple to implement. "I want this page to look the same on any size screen, whether viewed horizontally or vertically". OK. It's surprising it's as simple as it is.
> 'I thought implementing webfonts was a relatively easy procedure, but I guess not!'
No, it is easy. If you want to read 90 pages of marketing-promo disguised as a guide to fonts, do so. But you don't have to. Go to google fonts, pick one, add the URL to the head of your webpage, done.
> We’re a long way from the CSS Zen Garden where I started.
That way is still there. It's just slow and messy. You can still inline your CSS, use external css files. Whatever you want.
> Before, the websites could explain themselves; now, someone needs to walk you through it.
Before, scrolling text and gifs were the cutting edge of web technology. Now we have Photoshop, online IDEs, real-time trading applications in the browser. This is magic. And magic isn't easy.
Furthermore, modern browser element inspectors provide an excellent explanation of what's happening on a webpage.
The web isn't static - as the browser advances we use new tools to handle the possibility as well as the complexity. But the old ways are still available. Although I'm not convinced that the 30 minutes of mental overhead getting to know npm and flexbox beats the mess of external resources, duplicate code and utter pain that was the web of the past.
Everyone needs to take a step back and ask why they are building a web site in the first place. My local hair salon really just needs a brochure, and maybe a scheduling widget. A doctors office would need to add on a payment system. Both of which can be achieved by pulling in a script to use a 3rd party solution, while the core web site can remain plain, static HTML... done in Notepad, if you want to get really simple.
When you step up to needing some actual functionality, there still is a line in the sand where a few PHP scripts will do the job, and can just be pushed up to a shared web host.
When you cross that line, THEN you need modern tools. And many sites will need to go there. But a boutique design firm should be able to go a long way without, and probably could just hire some devs if they do land a project large and complex enough to need that level of code.
Just because you can go complex doesn't mean you should.