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.
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 that harkens back to "simpler times" in the olden days:
<title>My First Web Page</title>
My First Web Page
Even a web "document" like the wikipedia page on The Beatles 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.
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.
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.
There really are some really simple, really successful Web pages on the Internet. So, sometimes simple can be good enough!!!
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:
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.
Simplicity is the ultimate sophistication.
IMO, it's also ultimately difficult to pull off.
This is true, but the fundamental argument Frank makes in this article is just as applicable to web applications, if not more so.
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.
1) A brochure.
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.
8) Some kind of permission system to add additional people who can track patients data (could be relatives, other medical specialists, etc).
9) Connection to social groups (or even communities). This exists for rare deceases and deceases that aren't strictly medical.
And the default solution is Wordpress!! A full blown PHP application to just do a brochure.
You need to make an admin panel for your client. WordPress has all of that.
They want a contact form? Just add a plugin. No coding needed.
And WordPress is easy as heck to deploy anywhere.
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?
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.
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.
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.
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.
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.
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
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.
If you zoom out and think about it for a second what most technology is doing today is making a small guy look big
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.
Also I often think:
I keep hearing coworkers adopt particular open source project/framework with no understanding of what kind of problems it solves.
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.
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.
I think the ones doing it to make a name for themselves rather than solve a real problem are a lot less common than you're making it out to be.
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.
"If it ain't broke, don't fix it."
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).
Why can't I use tables?
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.
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.
I didn't see any good reasons to do anything special or different for mobile. What am I missing?
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.
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!
Thanks for the tutorial.
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.
Edit: SE answer with more: https://webmasters.stackexchange.com/a/6037/3403
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
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.
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.
A concise feature list can be found here: http://es6-features.org
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.
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.
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 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.
On the "sliding scale of giving a fuck" , 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.
People were saying that was the problem 10 years ago. Those exact words. Apps aren't docs.
All you need to do now is propose a new language and call it XHTML. Or maybe make markup extensible and functional, we could call it, ummmmmm, XSLT.
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.
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.
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.
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.
Still, I know what you mean. Blizzard had a pretty cool WOW character editor in XSLT.
If you used only certain stuff and never had to debug someone else's XSLT it was pretty awesome.
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.
XSLT 2 was actually usable. 1 on the other hand... it really did feel like a twilight zone sick joke.
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.
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.
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, 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.
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.
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:
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.
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.
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.
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.
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.
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".
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?
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.
> 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
A problem caused the program to
stop working correctly. Windows
will close the program and
notify you if a solution is
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
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
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
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.
No, Xerox, Microsoft, your
UIs are NOT "obvious". No,
you NEED documentation.
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.
SNMP is Simple Network Management Protocol
You probably want Outlook to do SMTP, Simple Mail Transfer Protocol.
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.
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.
>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.
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.
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.
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.
And no, that doesn't make Python and Java old hat or redundant.
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.
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.
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.
<center><table width="100%"><tr><td bgcolor="eee" colspan="2"><img src="foo" align="right" width="200px"><font size="1">...
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
<div class="center full-width" ><div class="col"><div class="gray col-2 small-text"><img class="right" style="width: 200px">
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.
You did create modern sites with CSS, without JS.
> [...] 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.
Also interesting is that it took 8 years for XMLHttpRequest to settle into the version ( 2 ) that supports accessing other origins ( https://en.wikipedia.org/wiki/XMLHttpRequest#History ) and that Internet Explorer didn't support CORS until version 10 ( https://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_re... ), which reached general availability in 2012 ( https://en.wikipedia.org/wiki/Internet_Explorer_10#History ).
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.
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.
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.
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’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered.
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.
Sounds like Elm  (pure, functional, very very easy to start with but lacks abstractions), Purescript  (pure, functional, powerful, the best language for the web right now, imo) or ReasonML  (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 , Clojure's  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."
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.
I would recommend Typescript then.
> 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.
Funny, all people using Typescript I know use it in functional way (computer vision/AR in a browser).
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
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.
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.
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.
x <- newIORef 0
writeIORef x 2
print =<< readIORef x
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.
 P. Wadler, The essence of functional programming.
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).
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
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.
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.
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.
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.
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".
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  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 , or Vue, React or Mithril if you want something more standard.
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.
I assume web assembly will bring sanity to the frontend PL world, which will be a step forward.
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.
I fully blame the virtually non-existant standard build- and module system in C/C++/JS for a lot of the current problems.
This is one of the reason I really want to learn Rust. Compared to make/npm/gulp its infrastructure looks heavenly.
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.
Python built linting into the language itself and it's super annoying.
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.
Well, I didn't make that argument.
ES6 is not almost a different language. It provided many good features, though.
>JS was and is a horribly designed programming language.
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.
Other people simply accept different trade-offs than 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.
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)?
You couldn't be more wrong. The toolset that you need to develop decent C/C++ programs is massive and took decades to develop.
They all have really ugly parts at least in JS they don't slow you down.
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.
The language itself is the last problem with JS
I guess worse really is better.
How exactly? I'm really curious. AFAIK it's pretty hard for a JS string to be casted into anything (pretty easy the other way around though).
I guess maybe parseInt can do that, but that's neither casting not implicit.
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.
That was published 9 years ago.
While I understand that a problem like this is unnerving, it isn't the rule.
People throwing around strawmen in here like nobodies business.
We can do this with all languages and tell ourselve we're using the "superior" language.
> 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...
> 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.
True, and we could go one step further: it's unambiguously defined, with invariant rules that can be used to prove a conformant implementation.
XMPP had been defined as formally: where have we ended up with it now?
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.
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.
Pretty cool! Learn something new each day :-)
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...
I think the main problem is everyone insists on over engineering a fucking website.
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?
Let me guess... you’re a JS dev and you think “little upvote arrows” are where the real value is?
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.
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.
Other than that Email is a good example.
npm install -g typescript
then put this in a tsconfig.json file:
then run tsc -w
you can tweak the compiler for prod or debugging output etc. with these flags for the cli or the json config: https://www.typescriptlang.org/docs/handbook/compiler-option...
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.
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.
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.
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.
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.
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.
At some point 10x less LOC has to be factored in as a significant benefit
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.
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.
This is not how it works.
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.
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.
There is no defacto solution for software engineering everything still sucks, and nobody remotely has it figured out.
The rest of it is like PHP (yes, I have programmed a fair bit in that as well).
> 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
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.
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.
Lib size differences are ~0.
What exactly do you propose? I will test it out.
I use Typescript as well.
Or maybe it's a highly misunderstood language because it doesn't match human intuitions. That makes it a poor language, like the OP said.
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?
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.
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.
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.
Except that native apps, in practice, don't do that, and websites routinely load 10Mb of JS when the user only wants to read a 5Kb article.
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.
* 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.
Anyway only recently has the community invested in improving this. Give it time, unless you believe something else can replace it before that.