I wish this was listed at the top of the list, in the middle, and at the end. It’s super annoying when a site or application isn’t “supported” because it wasn’t tested in a separate browser (i.e. non-Chrome browsers).

I know it’s not always easy with a fair amount of nuance which the Chrome Compatibility post[0] touches on, but developing the web platform should be done openly, with the browser vendors working together to be compatible with each other and not introduce developer or user inconvenience. Otherwise you end up with web ownership and a fragmented platform.

[0] https://news.ycombinator.com/item?id=23563525

The one with the greatest market share is incentivized to the contrary in order to cement their position.

My idea (when looking at the picture a tad narrowly, there's so many variables here) is really when it comes strictly to rendering content, all browsers should be the same. HTML/CSS/JS in one browser should produce identical displayed results/behavior in another. I'm all for the implementation being different, resulting in performance differences, differing external functionality and features, etc. But the core use, displaying content, should not be broken because you aren't using the browser the developer of the site/app was using.

1: Assuming they meant for the advice to apply to beginners rather than young developers - what age they are seems irrelevant.

Okay, this was long ago, but we had to roll out a new top-level website. I decided to be a complete hardass about it. Everything would validate, both for HTML and CSS. I would follow ADA standards as well as I could understand them. I dutifully tried things out in lynx. I even made some print style sheets (a new concept at the time). However, I had almost nothing to test on.

I got a lot of flak for being slow, we should hurry this up, and so on. And yet the emails would come in later from the higher ups, "Wow, this works on my Blackberry!" I had no access to such a device, but plodding adherence to various guidelines, as dull as they were, saved my bacon there. Even the disability folks I could find seemed pleased.

It isn't "move fast and break things" but you can reap a few benefits out of it.

Companies also frequently skip testing in favor for faster release times.

I've used Firefox for 15+ years now and never had the problems that people talk about.

On Linux, I use Firefox primarily for browsing, but for development I use Chromium. The reason for that is because the JS debugger in Firefox is pretty damn buggy. Some things I've encountered (though they don't happen every time):

- On a breakpoint, type expression in console, hit Enter and it just hangs there without giving you the result. The console will be unresponsive until you unpause.

- On a breakpoint in some part of the callstack, type expression in console and see that variables that should be in scope at that point in the callstack are not in scope for the console.

- Go to a different spot in the callstack and see that the place that Firefox tells you you're at is not correct. It might be off by a few lines.

This might be a very good reason why developers prefer to develop for Chromium/Chrome. Not because they prefer it for browsing or for its performance, but because its development tools actually work.

I made the switch recently, like a month ago, and I've been discovering little things that are just more pleasant when working in Chromium. For example "Copy as cURL", is formatted neater. Firefox puts all the curl options in a single line, but Chromium separates the options in multiple lines.

It's also wonderful that the browser is truly privacy conscious.

And also: Come on, that wouldn't make a browser slow. Users open new windows once when starting the browser. The rest is about how fast they render pages, react to JS workloads, and maybe how fast they open tabs. FF is more than on par in all of this.

Curious what you said about FF reorganizing the window contents, in my experience Chrome does that and not FF.

It's true JS performance is quite similar. But I've noticed (measured) differences in page load speed as well -- including latency again, the time until it actually responds to the enter key and initiates a network request. (In the network panel this is reported as Stalled.)

The modern equivalent is tuning uBlock Origin, uMatrix, Privacy Badger, or similar products, on top of correctly configuring your browser itself.

You also need a Mac to debug safari on iOs. I hate Safari.

Also, I agree. I have a laptop with about 256 mb of working ram, so I only use terminal apps with it. If I'm trying to look up documentation and the site doesn't work with lynx it is not a happy day.

And that doesn't even touch on servers.

That's what I don't understand. How hard is it to just make a plain text copy of the data to serve to people who want it instead.

Still, I think the list can pretty much condensed down to one point:

Use whatever technology is appropriate for this site or web app.

Because a lot of developers seem to have a 'when all you have is a hammer' attitude towards web development. They learn React/Vue/Angular/whatever, then seemingly decide everything they will ever build will use that framework, regardless of whether it's the right tool for the job.

A blog doesn't need to be an SPA. A static business site that never gets updated and doesn't do anything remotely interesting doesn't need to be an SPA. Your documentation doesn't need to be an SPA.

It's like that guy who was recreating CPanel as a WordPress plugin/install. Sure, you could do things that way, but may want to rethink whether this is really the best architecture to build a server control panel in.

At least where I live, small businesses contract with agencies that develop React sites for them, and suddenly these non-IT companies are owners of expensive and hard to maintain websites that they don't, and shouldn't need to, know the first thing about maintaining. No one wants to work with the projects, because they were written in, say 2015 React, back when React used X feature that isn't cool anymore, so it gets rewritten by another agency, and so on.

Meanwhile, WordPress on a managed host or a static site would suit those businesses just fine. Then, they wouldn't have trouble hiring to maintain it, or could even maintain it themselves.

If you work for an agency or you're freelancing, please stop burdening small businesses like this.

But, yes, I've seen countless businesses for which something like Wix is perfect.

1. Site builders are still hard to use for most marketing staff, if the site should look professional and you need a few small integrations.

2. They don't mind paying for a solution where someone else does the work.

I guess it's hard for marketing departments to pick an appropriate agency and to know the consequences of the technical choices the agency makes. They generally evaluate based on design and then have a few requirements like: resonable performance and support for a handful of features in the backlog.

> If you work for an agency or you're freelancing, please stop burdening small businesses like this.

There aren't many more soul-destroying experiences as a freelance developer than maintaining a neglected WordPress installation that was built by a maverick agency that took the money and disappeared.

These projects get completely rewritten because they aren't fun to work with for most developers. What is being ignored is that there is an immense pool of labor that specializes in WordPress et al, and they're relatively cheap to hire. Even if these companies don't have dedicated staff to run their sites, many people are capable of using WordPress as long as its maintenance is outsourced to a managed host.

I think theres some validity to "you're the most productive with whichever tools you're most comfortable/familiar with", but I think people don't realize the levels of abstraction that come with web development.

( My learning path was: Angular 2 -> 7 + sucking at CSS, Angular + Tachyons (learning how to style), -> Angular + Custom CSS for everything, to Vue + Custom css -> Plain HTML + Plain CSS. )

Its like the more you learn the more you understand the boilerplate of libs/frameworks, but also understand what these large tools accomplish for you, and then you learn to appreciate how powerful & simple the "vanilla" web can be if you open your mind to it.

[0] https://github.com/developit/htm

Disagree with this. Having the entire documentation site working as normal on my browser when I have bad/no internet connectivity is extremely useful.

[0]: most of us are not saying browsers shouldn't be allowed to run code, only that there's no reason why anyones statical documents should need to run code on my machine.

Even better, if your operating system has full-text file indexing, it'll be able to search them normally.

Edit: incidentally, a common way for this to work is that the documentation just comes with the software itself, so it's just sitting there on you computer. If the software updates, the documentation updates.

Websites like https://devdocs.io/ do this exact thing through desktop Progressive Web Apps.

Basically you keep your markup & source as static as possible, and allow a serviceWorker to cache those files locally. This can also be done with a SPA, but if we're talking docs, you get the benefit of only having to update a specific page if its raw html.

If you are a javascript developer chasing the bleeding edge of web dev, it's pretty close to real time!

Run this:

    find /usr/share/doc -name '*.htm*'

Your system's package manager is installing the HTML documentation right along with the software you install.

When you update your system, new package versions along with their corresponding documentation are downlaoded.

https://en.wikipedia.org/wiki/Doxygen

But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build this way, and so easy to deploy.

Sure, it renders slower. I've just signed my 25th professional client, and I have never yet had a client who even mentioned rendering speed, let alone was willing to make any trade-off for it.

Server-side rendering or writing raw HTML are over-rated.

I suspect that perhaps you've learned primarily front-end frameworks for the majority of your career (an assumption, sorry if that's not right), which will make it seem as though frontend is easy compared to all this mystery stuff you're not used to working with.

It's the same for me, but the other direction. I've always worked with server-rendered applications, so to me all that stuff is super simple and working with frontend technologies involved learning a swath of new paradigms and tooling, so it seems like the more complicated one.

I think the learning point for me is simply that you're probably not going to care about what my arguments for server-side languages are, because it's never going to map to your experience of them. Just like I don't agree with any of your general points in the second paragraph.

React isn’t too bad, as such things go, but compared to server rendering SPAs are such a slog.

There are good reasons to build them sometimes, but “fast and easy” is not one of them IME.

I was halfway through building a site when I switched to Vue. It ended up reducing the number of lines of code by 30-40%, and made the interactions much simpler to reason about.

Now that I know Vue, I think it's a vastly better way to develop than without it.

That's because understanding rendering speed is your job, not the client's job. What the client will be saying is things like "Why are my conversions so low?", "My site doesn't appear in search results." and "My friend's neighbour's dog-sitter told me my website sucks because it takes ages to load." It's your job to translate those comments in to meaningful actions, like optimizing rendering speed.

Which is sort of a weird point. So much of the web development blogosphere assumes that the reader is working on a site that sells some product direct to the public, who are very fickle, and will abandon your site quickly. Undoubtedly that industry does exist, but I've just never been anywhere near it.

If I'm able to render things from the backend, I just have to query the data and slot it into the page. No need to design an API that's flexible enough for application use but still inflexible enough to prevent security holes.

Also, if I decide later to update how the data is represented (a common activity in early-stage projects), I only have to edit only one thing instead of two things.

On the code level, it's really not all that different - the operations you perform 'directly' through function calls in a pure server render model you simply put behind another HTTP interface.

I get that this mapping work might be a bit cumbersome and take some extra work, but I'm unconvinced that it introduces some kind of security tradeoff - the client ultimately has the ability to call through to exactly the same operations, just getting the data back in a different format, right?

Instead I have to figure out what data access patterns my frontend will need and implement those, along with whatever visibility restrictions are required. I'm forced to do the former in the backend (as well as the frontend) because the latter can only be done in the backend.

(Aside: I realize that back in the day people did indeed use database mechanisms like DB users and stored procedures to do what I describe, and then client apps connected directly to the database. But this practice seems to have faxed and isn't readily doable on the web anyway).

    > (Aside: I realize that back in the day people did indeed 
    > use database mechanisms like DB users and stored 
    > procedures to do what I describe, and then client apps 
    > connected directly to the database. But this practice 
    > seems to have faxed and isn't readily doable on the web 
    > anyway). 

That said, I actually agree with your preference for server-side rendered applications. The problem is that from the browser, you can't really do anything that is not SQL -- you can't, for example, call into a C library, query a legacy API, and so on. Of course, all of that can be solved by deploying more microservices, but that not only means you have to think about API design again, it also increases operational costs. Unless you need lots of fancy live-updating things, server-side rendering is still fine, and even when you do need to update dynamically, there's Blazor Server now.

> "client should only be able to perform certain kinds of transactions and mutations"

The solution to these is equal for server rendered HTML containing {data} or an API just getting {data} in raw form - the request contains an access token which identifies and authorises the user - same goes for mutations on {data}.

The answer to the question 'how do you know who the user is when they request a server rendered page containing some sensitive data?' is literally the copy/paste solution to how to do authentication on your API - as in, it's basically the same code that must be implemented on the backend in either case :-)

The point is it's the same data and mutations, just a different interface over them. There is no security tradeoff of using one over the other.

No, it's not. If I expose an API e.g GET /widgets,I need to ensure that there is no combination of parameters that will ever return a widget that the user should not see (e.g because it belongs to some other department).

Whereas when I render a web page server side, I just need to write a single, correct, SQL statement that pulls in the widgets that this specific web page requires.

It's the same data, with the same auth needed. If it's accessible to anyone over the network you need auth for everyone in either model. The auth code is the same code in either model, only the interface changes.

Looking at your example to illustrate: you have user A and user B, who have permission to see different types of widgets depending on what department they belong to.

--

Scenario 1: filtering per-resource

There is a server-rendered /widgets page that lists all widgets, filtering based on what types of widgets the requesting user can see.

API implementation: /widgets endpoint that returns a list of all widgets for the client to render. It must filter based on what type of widgets the requesting user can see, so that only widgets they can see are included in the list. Same logic as above.

--

Scenario 2: grouping resources and authenticating at entry

There are different server rendered pages for each department, listing all widgets for that department: /widgets/foo-dept, /widgets/bar-dept. You must check the permissions on the requesting user before rendering the page, to see if they have access. If user A can't see foo widgets, you give them some kind of permissions error when they request the /widgets/foo-dept page.

API implementation: Add a dept param to the /widgets endpoint that lists only widgets in the specified department. If dept param is populated, check that the requesting user has permissions to see widgets in that department. If they do, proceed, if not, throw a permissions error and deal with it on the client to produce the exact same UI as in the server rendered example. Same logic as above.

--

If you have resources accessible over the network, and you do auth on them based on user attributes, you have to do that auth either way, regardless of if you're server rendering the data into HTML pages or returning it as JSON or whatever else and rendering the HTML on the client.

The goal of both applications is to display HTML. The duplicated work in an SPA is in the DB API -> JSON API and JSON API -> page steps. These steps involve telling my backend server about how my data are structured and how to interpret them, translating them to JSON (or something else), then telling my frontend the same things. Every SPA I have seen involves doing this work, although some (like Meteor) are designed to reduce it as much as possible. That's the standard work involved in an SPA.

The second half of my point is that you could remove this duplicate work but doing that gets rid of any security. Why is this? Let's look at my SQL API example again. In this example, I have effectively eliminated the duplicate work of making my app server aware of the data's schema. It just runs a query, serializes the blob that comes back, and returns it. So why not do that? Obviously because now I'm trusting the client too much. In a non-SPA world it's fine to trust the entity making queries (for the most part...let's not get derailed). In the SPA world it's not, so we inject the app server in between to do mediation, and we pay the cost.

In my experience, it hasn't been the case: designing a REST API (I know REST complexifies the API compared to tailored RCP) that behaves properly for the client is magnitude more work than rendering HTML with data server-side.

The main difference is switching the question from "what does this page needs to render for this user", to "what are all the things the front-end might want to access through this API for this user, and how do the front-end plan on filtering". The former is obviously easier to answer, and as the result easier to code.

Honestly most of the time you can even just cut out the REST layer except where it overlaps with views by coincidence. For instance in practice there are quite a lot of views which simply get a single resource, or list a single type of resource with paging.

For mutations I am a big fan of just doing it RPC-style. I know it's not to everyone's taste but I feel like abstracting mutations out behind a model of RESTful resources and verbs is, 99% of the time, a waste of time, the notable edge case being where you truly need a flexible API for 3rd parties (both apps with UIs and scripts) where organising functionality in this completely generic flexible way - with the considerable extra effort that you mention being the price to pay - has huge payoff.

100% agree. But that (authentication) is not what this thread is about.

> The point is it's the same data and mutations, just a different interface over them. There is no security tradeoff of using one over the other.

100% agree again. A properly written application makes no security trade-off here by using an API. But that's because a properly written SPA stack does the work of interpreting the data and it's relationships twice on both the frontend and backend.

This section also frequently applies to security.

> but still inflexible enough to prevent security holes.

Unless it involves a transaction or government secrets, security is usually way down the list of priorities.

Tell me that React websites today will still be around in 10 years time. With constant upkeep and maintenance, maybe. If a website is just a static website, not making it plain HTML is a disservice. The layers of abstraction will take its toll.

On my website I have pages which date back to 1993-94. Still readable just fine. I used to post those links to mailing lists back then and they still get regular hits from people in that community because I've also maintained the URLs constant.

In my professional life though, I realised that 95% of the things I build will be changed in the next year or so. We often inherit projects that were only just finished, and our first task is to start changing it entirely.

So I aim for robustness of maintenance rather than robustness of the finished product. It's inevitable that it will change, but I can anticipate that in the same way a well engineered car can anticipate it's maintenance cycles.

My agency regularly take over older JavaScript projects - built in whatever JS-stack was trending at the moment. There are always big parts of the stack that are no longer available or in active development. Not to mention the enormous hassle it is to bring dependencies up to date for a JS-project that hasn't been updated in three years.

Depending on the circumstances we usually recommend moving it to a boring CMS like WordPress unless there are compelling reasons to double down on the JavaScript stack (if it really is more of a web application for example.)

As an industry, this is called job security. It is fascinating to be in an industry where systems requiring high levels of maintenance are preferred by the client.

Large entities have need and budget for their applications to evolve. The delta for websites is less intensive. For the latter, reliability and longevity is important.

[1]: https://developers.google.com/web/updates/2019/12/chrome-80-...

[2]: https://stackoverflow.com/questions/30876093/will-chrome-and...

I can explicitly tie together components/html client side via JS (annoying). Or I can simply render the correct html (no need for json routes) while I have access to all of the data on the server. Rendering speed as you mentioned (client or sever), is basically never a consideration.

So why bother explicitly writing javascript to bind html components together when I could just simply render the correct server side HTML?

Ajax is fantastic, but you don't really need an SPA.

If you want to be wildly productive, minimize the javascript you write.

I'm a big fan of intercooler.js btw.

the differences are rather in the architecture.

you can win or loose a lot there, by choosing the right or wrong one.

by creating an SPA you win a much simpler backend, you separate data storage and processing from data presentation.

you win the ability to have multiple different frontends against the same backend, or run multiple backends against the same frontend.

you win the ability to upgrade/replace backend or frontend independently.

you win the ability to develop with multiple independent teams because the connection between frontend and backend is smaller and easier to define.

you win the ability to reuse generic backends over multiple projects...

these are a lot of advantages, if you need them.

but there are downsides.

you no longer have a single codebase.

you need to maintain an API

rendering is slower in the browser.

depending on what kind of application you create, you may need to be careful to not put any business logic into the frontend. (anything with business logic goes into the backend with an api to access it)

it should be clear by now that i am a strong supporter of this architecture.

i may miss some downsides of an SPA and i'd love to get more input on other potential downsides, however, loss of productivity from writing javascript is not one.

You are obviously writing more code for client side HTML generation based on JSON than regular server side rendering... I am saving effort if I need to write fewer files...

Your feature requires a JSON route, html rendering, and javascript that pulls everything together. Mine is just a route that returns HTML. Why is there absolutely no difference in effort? You have 3 files, I have one.

separating data from presentation is not new. It has nothing to do with SPAs

i have used different backend and frontend frameworks, and i found that backend frameworks do not make things simpler in the sense that you are talking about, if you want to create clean and maintainable code.

sure you can put everything in one file, but the number of files is a meaningless metric. more useful is the number of functions and abstractions. an API is an abstraction. you can do away with that if you generate html in the backend, but the price you pay is with a much closer coupling of interface and business logic that will make future changes harder. in any sufficiently large site you can't afford that and you end up rewriting your site to create the same architectural complexity simply because you need it.

SPA frameworks query the server for JSON and then render HTML right?

Simpler in the sense of what? You prefer to not have all of the variables available when you render HTML? It's simpler to only render client side HTML and to query 4 different AJAX endpoints for resources?

Why are you trying to separate business and interface logic? Why are you displaying anything that the business logic doesn't understand?

The entire point of good code is that I can edit 1 file instead of editing 3.

Back end frameworks don't help you organize code? That's kind of their point?

The end result looks very similar to the server side frameworks of old, so it's a bit of a circular evolution. I think only using one programming language (the one that is part of the web platform) and a solid, template free component framework make it incrementally better though.

You can still and should have an API but it will be an internal one(in-process, not at the network boundary).

The code inside the API is an abstraction.

> you win the ability to upgrade/replace backend or frontend independently.

> you win the ability to develop with multiple independent teams because the connection between frontend and backend is smaller and easier to define.

> you win the ability to reuse generic backends over multiple projects...

None of these are really specific to SPAs, they apply to any architecture with a separation of concerns.

It's simpler if you only write the front-end, because it de-couples the work with the back-end.

If you are in charge of both front-end and back-end, server-side rendering is easier.

It's a case of Conway's Law. Knowing that, you may choose to have a back-end team and a front-end team or a team of full stack developers depending on the end result you want.

Personally I think it depends on whether the Web is just another client for you, which consumes APIs like native applications, or if your product is entirely web-based.

This is nonsense.

Both the frontend and the backend influence the design of each other(and for good reason). The notion that you can build one without the other and be done with it is just wishful thinking.

There are very few upsides if you already serve pages server side and look at current client side js development.

Because they rarely know about it. And why would they? It's a very technical choice. Factoring in things like render speed is your job when picking the most appropriate solution for the problem at hand. When you're doing this you are placing your own comfort and ease above that of anyone using the site. Google already factors site speed into rankings and with all the Web Core Vitals stuff they've been pushing lately it's only going to be more important. You're failing your clients.

https://knowyourmeme.com/memes/money-printer-go-brrr

If your clients are like mine, there are likely a lot of things your clients don't ask for. For instance, accessibility. Do we ignore that as well?

You're also not factoring in ongoing maintenance. What's easy for you to build and deploy might be less so for someone else. React, Vue, etc. are great tools - when they are the correct tool for the job - but they are still relatively niche. If you're not taking a "what if I get hit by a bus approach" then you're doing your clients a disservice.

You might want to try being a typical user for a month or so. Use a smaller monitor, an older mobile device, a slower internet connection, etc. Then take that lens and apply it to your SPA genius.

Well, some of my clients are government, so they do care about accessibility. For the rest, I put in some effort, because it's the right thing to do. (As opposed to rendering speed, which I really don't think matters, within reason.)

Just to be sure: These two are not the same and server-side rendering does not necessitate writing raw HTML. In fact, I think that most advanced languages used on the server-side have means of not writing raw HTML. There are template engines and some languages offer SXML, which already provides you with a kind of template engine.

Personal opinion: I really don't like having to write raw HTML in form of it being just a string, allowing for all kinds of markup issues, formatting issues etc. A programming language or used framework/library should have awareness of the HTML tags and prevent mistakes. SXML prevents mistakes in nesting for example. In Racket and I think in Scheme dialects as well, SXML prevents cross-site scripting by design as well. What many many people get wrong is how they split up their documents. They forget about composability and use only concatenation (looking at you, wordpress themes ...). This severely limits reuse of code. Good templating languages try to nudge you into the direction of making things composable.

I get that most of the web and most of what web developers do these days are just regurgitations of the same basic website designs. But man there is some really powerful tech in JS and WASM just waiting for someone to make brilliant stuff from.

Never trust the state of the client... Never trust client's input...

No idea what JSF is. Sorry it didn't give you access to the data you needed when you rendered files.

So yeah it happens.

Their old server side solution was near instant.

Definitely the design flaw was to index it in the frontend in the first place instead of preparing that data somewhere in between to easily be consumed by the client but still draws the picture of how many people approach SPAs these days.

Amazon, Google, Walmart, Mozilla, and Yahoo all have numbers that say otherwise.

"Amazon and others found that removing 100 milliseconds of latency improves sales by 1%."

I'm 100% sure there are people who care about 1% differences in sales, and the fact that has been rediscovered independently by different organisations shows that "people" at least "aren't happy" with very small increases in page load times, at least when making purchase decisions. (Whether that extends to people reading your latest blog post or endless scrolling your social media site's newfeed is a reasonable question, which I'm not sure 've got a good enough handle on to have an opinion worth sharing.)

(From an earlier HN submission today: https://instant.page/ - click the [1] link n that page after that "Amazon and others found that removing 100 milliseconds of latency improves sales by 1%." sentence for sources.)

There might be people that misuse SPAs when server side rendering is the better choice but SPAs clearly have use cases that are not possible with just HTML.

Sure, but that's pretty much cherry picked whataboutism when the parent comment we're talking about said: "Most people are happy if the page loads in reasonable amount of time".

So apart from people writing chat messaging widgets for websites, do you have data to contradict the conclusions about webpage load times and rates of change of user behaviour that can be obviously drawn from the Google/Amazon/Walmart/Mozilla/Yahoo data?

That said I am definitely one of the people for whom it does matter.

- 10ms response time for interactions (scroll, click, entering text)

- 100ms for in-page context switch (changing tabs in a dashboard, loading the next picture, etc.)

- 1000ms for page load

these are obviously rough guidelines — page load in particular is obviously gonna depend on your user’s internet speed if you have any kind of media — but they’re helpful when thinking about “reasonable”

Modern web is serving people mostly with nice looking shit sandwiches.

It has nothing to do with standards, businesses don't care about standards in the long run, they care about making money.

If I write something in Django, I can let the forms be auto-generated to whatever degree I like. If I do it as a SPA, I essentially need to twice as much work, as I have to write a backend to serve and consume JSON and a frontend to display and interact with it. Then you have got the nightmare of debugging the mess.

8) learn a statically typed language with a good type system

Even if you end up preferring mainstream language X, learning a language that makes you think in expressions rather than operations, and a language that makes you think in contracts rather than knowing the runtime state in your head, is invaluable for learning how to design, structure and maintain a codebase

Personally I have never really seen the advantage of staticaly typed languages over say Python, but I do rely on the strict typing supplied by a database instead.

But it also serves as documentation of how any part of your program's state is structured at any point. To the degree a type system is sound, and to the degree your types are appropriately detailed, you can be assured the documentation is correct and up to date as long as the program compiles. This allows you to eliminate the question of "what does this data look like?" when you're reading code, and focus more on things like whether the logic is implemented correctly.

Since you mention it, I'll add that Python does have (optional, gradual) static typing, and a lot of work has gone into the type system in recent versions. It's worth spending a little time adding some static types in a project and seeing some of these benefits. When I last worked in Python, you had to run `mypy` to actually fail on static type errors, I don't know if this is still the case. But you could also use an IDE (like PyCharm, surely there are others) which will at least surface static type errors while you work.

An example: threading macros. In a language like Haskell, partial application is optimized for left-to-right. `f a` substitutes the first argument; other orders are more awkward. Functions like `map` deliberately place the "most known" arguments first to aid in partial application. If they guess wrong the code gets twisty.

But Clojure's threading macros compose functions, while just letting you say where you want the argument to go:

  (as-> [:foo :bar] v
     (map name v)
     (first v)
     (.substring v 1))

Sadly no DayJob language has features like this, and Clojure has other weaknesses which become apparent rapidly. Clojure learning will leave you yearning.

Clojure has lots of strengths which also become apparent the more you works with it: async, thread-first, thread-last, transducers, core.logic, (partial f a), flexible composition, expressive-ness unrivaled in Dayjob language, hundreds of functions that just work on whatever data you're dealing with, tapping into java "dayjob" libraries without having to deal in actual java. The list goes on.

I've re-written a few applications & libraries from javascript (and other dayjob languages) -> clojure(script). In every case, the lines of code drastically dropped, the functionality expanded, the readability improved, and performance was always on par or better. It's not a silver bullet for everything, but its strengths far outweigh its weaknesses. Like any good mind-expanding drug/language.

> Clojure learning will leave you yearning.

It has been my experience with learning clojure that with each new problem, it has left me yearning ... to learn the more elegant, composable, flexible, robust solution ... in clojure! YMMV.

I must say, having learned Clojure (and ClojureScript) and used it in production in my day job (we even still have one ClojureScript project in production), I strongly disagree. I would probably not choose to use it again, mostly because I've come to prefer static typing, but quite a lot of what I learned from learning it (and learning its idioms) has greatly improved my work in other languages.

In particular, Clojure's approach to state is something you can (mostly) apply in most mainstream languages. Handling most runtime state as immutable values, with clear and explicit use of mutable state for the cases where it's either necessary or makes the code easier to understand/more maintainable, is a huge boon for developers working in imperative languages.

In my current job, I've seen the quality of projects improve drastically as I've lead by example with that approach, and as I've asked for changes like it in code review. I've seen the volume and severity of bugs decrease, developer productivity improve, and morale trend upward.

Mostly the appeal is how easy it is to extend the syntax (because there is barely any syntax at all).

Disclaimer: I have written a good hunk of Emacs Lisp and also written Scheme professionally, but I have yet to grok macros.

However, I believe they're much more debuggable than dynamically-generated functions in most languages. There's another layer of translation from your baseline code, but due to the nature of macros, you can usually just step right into them and see the expanded, generated macro code, if my rusty memories of debugging elisp are correct.

Here's one person reading about Common Lisp's debugging infrastructure, FWIW.

SICP really gives you a “full-stack” appreciation for software (from applications down to compilers and interpreters). It’s horizon-expanding.

I think you're using a weird definition of 'edge' here to mean "things that nobody else knows about" rather than the cutting edge of the industry/academia.

Academic publications occasionally float across the front page here that have only been public for a few days. That's pretty much the 'edge' of industry-wide knowledge.

If you want to include things that aren't public, that's super vague and sort of pointless.

D'oh! Why didn't I think of that?

To people who doubt it, keep in mind that 10 years is a very very long time. Rust is not yet 10, Go is just barely 10. React is 7 and jQuery is 13. Cloudflare is 10, Stripe is 10, Hashicorp is 8 and Docker is 7.

https://github.com/begriffs?tab=overview&from=2016-10-01&to=...

How many projects are there to automatically API-ify a database with auth boilerplate today? At least a few well funded ones, one recently funded by YC even.

They came up with it in 2015? 2016? and still have a thriving project going with it. Looks like less than 10 people have more than 10 commits in its history:

https://github.com/PostgREST/postgrest/graphs/contributors

That's a really vague statement but you described phpmyadmin, django, wordpress with a plugin, etc. Most successful CRM companies essentially have some framework doing this underneath as well.

Thanks!

> Always validate your data server-side; anything that comes from the client is suspect.

At least sanitize in a way that won't break the server but will throw an error. For internal applications and side projects it's ok to just respond with a 40X or a 50X and move on.

> To the developer, “isomorphic” code breaks down the barrier between client and server.

"Breaks down the barrier" sounds great, but it's actually has been rather detrimental. "Isomorphic" is confusing even to the senior developers. Having a very clear delimiter of what runs in the server and what runs in the client is essential, and it makes your application much simpler to reason about. Take `isomorphic-fetch` for example... a request from a server to another API server has very different requirements and nuances than a request from a browser to a server.

If you need to sanitize to avoid breaking the server then the server is already broken. Also, never sanitize, validate on input and escape/encode on output, but sanitization (meaning removing/cleaning invalid input) is the wrong way.

If you’re not _very_ careful with your software architecture, you can inextricably tie your frontend and backend applications together. Depending on the size of your product, or why the growth plans are for that particular frontend/backend app end up being, this might not be a problem.

If it becomes one, though, then every bad technical design decision made in that `common` set of modules or packages ends up hurting you as it gets unspooled from (at least) two components that likely have very different architectural idioms.

The remaining coordination issues can be solved by documenting or using e.g. a '@Deprecated' decorator in Typescript. And, of course, you can always just remove a field to see where the code has dependencies on it (where code breaks during compilation).

The concerns about shared code may apply in some cases, but the global schema is not one of them, in my experience. I do agree it takes a bit of extra thinking to do this correctly but it's really not that difficult.

Huh? I don't follow this. Sharing some helpful util functions between the frontend and backend doesn't allow malicious clients to control your server.

Form validation is a common example of where things can break, like someone injects malicious data that's already been validated by the client-side code and then the server assumes that the code has already been validated by the client.

And if you don't even know which code is running where, that makes it even more dangerous.

(For what it's worth, both are really really cool technologies!)

Edit: But I also suspect this relates to a temptation to write browser-side Javascript without thinking about the server-side or database; IE, browser-side Javascript that just loads objects willy-nilly via fetch / AJAX and creating lots of round trips.

Young developers, if you can spare a moment, try to learn what REST (and HATEOAS) really meant:

http://intercoolerjs.org/2016/01/18/rescuing-rest.html

http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...

If I had to pick just one, it would be this.

It makes me think that it's not inherently bad, it's the technology that's lacking.

If the file explorer would split a 1000 file listing into 10 files each it would drive anyone insane. The "Artists" list on my phone's music player can probably be meassured in meters yet it's a joy to use because momentum scrolling is very good.

“Infinite scroll” means you can never reach the end, because every time you get close to the end, more content is downloaded and your scroll bar readjusts. There is theoretically some end to the content, but most users will never reach it. Examples are Twitter and Facebook feeds.

This is my fave:

> Infinite scrolls are inhumane. People need to be able to reach “the end.” There are forms of eternal torment described in religious texts that are less mean.

EDIT: I've updated the Tumblr version to make this a bit more clear.

<details> <summary> It's not a good idea </summary> really. &lt/details>

The most ignored

Anyone knows of some easy to learn example of such DOM replacement?

Let's rebuild html rendering, navigation history, forms, etc, all with Javascript, because it's the hip thing to do.

1) Prevent reloading of the page every time the user clicks a link, reducing the overhead of fetching common content between pages multiple times (headers, menus, etc) and providing a more seamless experience to the user.

2) Better emulate the feel of mobile applications, for users who spend most of their time on their phones and don't often or have never interacted with a computer. Yes, those exist.

3) Improved network performance (by sacrificing initial load time). Once the browser downloads and caches the bundle on initial load, the user can revisit the page on regardless of their connection stability or speed.

This isn't to say SPAs are a perfect choice in all cases (they also have just as clear drawbacks), but saying "it's what everyone does" is the only reason they exist is downright false.

You don't need a SPA for that. And page load/render times are much shorter when html is delivered straight to browser fr most applications

> Better emulate the feel of mobile applications,

That's pretty weak defense.

> Once the browser downloads and caches the bundle on initial load, the user can revisit the page

Giving we're now in the world of Continuous Deployment, I doubt the cache lasts long.

All 3 of those reasons sound very reaching to me.

And here's the kicker - doing a SPA well enough to be seamless and performant is hard enough that most sites suck if they're delivering a SPA.

Also, if, for example, you do your payments or other sensitive pages in a SPA, you're still running 3rd party scripts on those pages for no reason. Let me know when unloading scripts(&their in mem code) is doable.

Are you legitimately worried about unloading third party libraries into memory on the browser??

or else gaining the ability to freeze their code and all derived/generated code from accessing the dom/network/etc.

Please don't misuse words, especially in a negative context to mean "something I don't like", it cheapens the word in legitimate cases.

No comment on whether SPAs are worth anything though, I reserve my opinion.

you've never seen certain architectures that smell because they're not following an established pattern?

Not sure you could ever call them an anti-pattern.

Assuming you add video, 99% of the web is just text,images,links,forms, and video. None of these things even require Javascript.

Or is your opinion that it should only be possible to do those things in native, purpose-built apps? Because in that case, how do you justify using an operating system? Perhaps we should exclusively use purpose-built assembly code that you flash to some writable media every time you want to run a particular program!

Also, a SPA is not the only option with Javascript.

1) Load the page.

2) The page is now fully loaded and ready for reading without any need for further network requests.

For even more offline use, try printing it! HN threads work superbly when printed, again unlike most modern sites.

Or you could reimplement newsgroups (but with less interoperability) as an SPA, which in theory would work great (once you work out the kinks) but in practice would suffer from all kinds of little issues in the from-scratch reimplementation of everything. For example, printing would probably forever be a wishlist item in the backlog.

A lot of people think that moving to an SPA would mean killing both those aspects. But the truth is, you CAN have an SPA that is both lightweight and fast - the developer just needs to know what they're doing.

https://community.nodebb.org/category/2/general-discussion