Hacker News Reader

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.

>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.

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.

That's a really good point.

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 ;)

> blah blah blah

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.

> want to make a name for themselves with a "real" project

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.

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]

"If it ain't broke, don't fix it."

1: https://w3techs.com/technologies/details/js-jquery/all/all

2: https://getbootstrap.com/docs/4.0/getting-started/introducti...

> 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).

Many sites hang onto jQuery solely for the Ajax abstraction that allows older versions of IE to function.

Also, WordPress includes it by default, but rarely are the site admins actually doing anything with jQuery.

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?

Why can't I use tables?

> 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.

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.

Okay. Thanks.

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!

Thanks for the tutorial.

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.

Edit: SE answer with more: https://webmasters.stackexchange.com/a/6037/3403

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.

ES6 is elasticsearch 6, right?

> ES6 is elasticsearch 6, right?

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.

[0] https://en.m.wikipedia.org/wiki/ECMAScript

ECMAScript 6, an expansion to JavaScript.

A concise feature list can be found here: http://es6-features.org

>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.