Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Second-Guessing the Modern Web

macwright.org

Post reply on HN
Print view View original

401–410 of 467 posts

Re: Second-Guessing the Modern Web

#401

Post by chipotle_coyote »

inapis wrote: post #299
chipotle_coyote wrote: post #183

Earlier quoted context omitted.

I think the problem/frustration is simply this: there are a lot of web sites out there that are, well, web sites, not web applications. Looking back at the linked article, it goes out of its way to talk about many ways that React is "pretty great" and "for a particular scope of use cases it's the best tool you can find," but then goes on: > There are a lot of problems for which I can't see any concrete benefit to usi…

Your argument hinges on the assumption that the products have a final conclusion. I can start building a product in hugo, say - I’m just displaying information in charts and generating predefined reports. Time passes more users are added and now I need to identify each users reports. Now I need a server and at this stage I can get away with SSR. More time, more organizations, more complexity. All of this can still be…

I would say rather that my argument hinges on the assumption that the majority of web sites in the world are not the primary products of the companies that produce them. I would argue, in fact, that you're looking at web sites from a very particular lens. An absolutely valid lens, to be sure, but a particular one. nonetheless.

If you're an SaaS (or PaaS or whatever-aaS) company, then your web site is literally the core of your being. You're building an application that happens to run in the browser, so you want to build it like an applications! But a lot of companies aren't doing that. Hacker News, the web site we're on right now, doesn't need to be an SPA (and isn't). Does any CMS need to be designed like one? I'd never give a blanket "no," but I'd sure never give a blanket "yes." How about a company blog? A simple storefront? A customer-facing restaurant site?

Also, don't get hung up on my particular example of a static web site -- I wasn't arguing that all sites can be done with Hugo. :) But you could absolutely design a modern, maintainable CMS that lets internal customers generate their own reports, write their own queries, and define their own templates using Rails or Django or Laravel as the back end -- and that seemed to me to be what the original article was really trying to get at. We've gotten so hooked on "JavaScript is everything everywhere" that we may not always be considering whether a given project really fits that paradigm. "This project doesn't fit it now, but it might in the future" is nearly always a technically correct response -- but "what you're building couldn't possibly scale up to unicorn level" is nearly always a technically correct response, too.

Re: Second-Guessing the Modern Web

#402

Post by marcosdumay »

danjac wrote: post #320
1337shadow wrote: post #297

Earlier quoted context omitted.

For me the real subject would be "the death of templates in favor of decorator based objects", which could have been predicted by the GoF that recommended the decorator pattern for GUIs, and makes great sense for the tag-based language that HTML is. Template languages often impose language limitations to make easier for HTML/CSS coders to work with, without breaking the backend code, isolating their codebase from the…

Seems we are going full circle: the Python ecosystem had component-based template languages such as ZPT (Zope Page Templates) and Genshi. The former I think is still used with the Pyramid framework, but mostly these approaches have been replaced by Django/Jinja2 text-based templates. So in Jinja2 or Django you would have something like: {{ page_title }} But in ZPT: Sample Page Title If you squint hard enough this doe…

It was that the template engine got a Turing complete text declaration language, while the tag based one had to rely on hacks that didn't scale very well. Also, as you said, because the template engine were useful for any kind of data, while the tag one carries a lot of opinions about the resulting text.

More flexible and conceptually simpler tend to win over time, as people try to learn less things.

Re: Second-Guessing the Modern Web

#403

Post by marcosdumay »

deiznof wrote: post #326
grey-area wrote: post #214

Earlier quoted context omitted.

for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time The premise of the article is that they are not easier to work with and do not save time in most situations. I agree. Most websites are fundamentally documents, even those that think of themselves as apps. You could even build gmail quite easily as a document based app with some limited use of fetc…

>Your about page is not improved by using react. Well...fortunately people don't use React for making About pages. These examples of why not to use React in these comments are silly, people use them for web apps 95% of the time.

> fortunately people don't use React for making About pages.

No, About pages are out of fashion and people don't do them in high numbers anymore. But they do use react to display news articles, web shops, and all kind of text.

Re: Second-Guessing the Modern Web

#404

Post by marcosdumay »

rimliu wrote: post #322
luxphl wrote: post #47

I empathize with the author but client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. It's true that they are largely more complex than O.G.…

I wonder, when did this shift happen wrt the Web: we only care about how it is easy for the developers, not for the users. Despite all the talk about UX a lot of the momentum is still in the wrong direction. I've been writing working with the web close to 25 years now. It is amusing to see it come the full circle. How hard it is to understand, that you don't need react for some blog, or anything which is not even rem…

> when did this shift happen wrt the Web: we only care about how it is easy for the developers, not for the users

Are you talking about the same web that ditched XHTML because you had to validate your site before publishing? And had those "works better on Mozaic in a 420x340 resolution" warnings?

Re: Second-Guessing the Modern Web

#405

Post by theonething »

amw-zero wrote: post #45

We should create a better division in web standards between the "document web" and the "application web." I think there are valid use cases to both, and we shouldn't rule out either. Wikipedia has to be the greatest realization of the initial spirit of the web: an endless interconnected network of articles of varying topics. That's a real use case, but it's not the use case of _every_ application. Some applications r…

Your conclusion is hard to disagree with. I don't think anyone's saying all apps should be SPA's or no apps should be SPA's

I think what a lot of us are saying here is that SPA's in general are overused in our industry when simpler solutions are more appropriate. And that's having a negative effect on productivity and developer happiness.

Re: Second-Guessing the Modern Web

#406

Post by pier25 »

lhorie wrote: post #399
pier25 wrote: post #379

Earlier quoted context omitted.

> There _is_ a runtime in the form of repeating patterns of code Obviously there has to be some running code at the end, and technically you are right, but I think you're splitting hairs and for a brief introduction it makes more sense to say that there is no runtime. Also I think I implied your point with "Svelte is just a simple way for you to write vanilla instructions". > Newer libraries do have centralized runti…

I'm mostly worried about the _optics_ of saying there's no runtime, because if people think "hey Svelte looks cool BUT I'm scared my bundle size will be humongous", then they won't convert. And Svelte sure could use some more adoption to get the adoption snowball going. That's all that it boils down to.

I could be wrong, but I don't think bundle size is the major concern people have over switching to Svelte.

BTW adoption is growing nicely:

https://npm-stat.com/charts.html?package=svelte&from=2016-05...

2020 is close to the downloads of 2019 and it's only May.

Re: Second-Guessing the Modern Web

#407

Post by pier25 »

tomaszs wrote: post #396
pier25 wrote: post #101

Earlier quoted context omitted.

Obviously Svelte can't do nothing about the misuse of Svelte (which is one the major points of the article) but: > The level of abstraction that React works on is too high, and the cost of using React - in payload, parse time, and so on - is too high for any company to include it as part of an SDK. Svelte is just a simple way for you to write vanilla instructions. There is no runtime and practically no framework. Oth…

Real World application written in Svelte requires a lots more libraries and code to supplement parts Svelte does not provide. So in the end you still have a big chunk of data. Svelte does not make the problem dissapear. Svelte does not provide a solution. Svelte has exactly the same problem like React.

In my experience I've found it's quite the contrary. I need less libraries when using Svelte.

Re: Second-Guessing the Modern Web

#408

Post by marcosdumay »

jakelazaroff wrote: post #223
dahfizz wrote: post #94

Earlier quoted context omitted.

I've often said that web development has a big culture problem. In any other field, 'modern' is the opposite of a selling point. People want tools that work, that are proven and have years of stability and momentum. But in web development, there is an obsession with the new and shiny. It's 100% about the developer's own experience in creating a program and 0% about the user's experience actually using the half baked…

Is that really true? On the backend, shiny technologies like Go have been exploding — Go modules only stabilized this year ! Since React was released, we’ve gone through through at least two new ways of deploying a server — containers and serverless, replete with their own huge abstraction layers like Kubernetes — and we’ve moved from monoliths to microservices and back again. And in native land, the “Rewrite It in R…

I have just recently been tasked on estimating how many people in our city would fit your standard job requirements if we applied them to Go... since the requirements are legally necessary, we had to ditch any plans of using the language.

I don't think "exploding" is the correct word, although it is growing.

Re: Second-Guessing the Modern Web

#409

Post by dbmikus »

unclebucknasty wrote: post #227
dbmikus wrote: post #190

Earlier quoted context omitted.

I'm actually more of the opinion that a lot of backend is bikeshedding! Branding and UI/UX design are very important for emotionally influencing a customer's opinion or improving their user experience with your product. On the backend, how often are the any different than some cross set of options from: * synchronous CRUD * async data flow * bidirectional realtime messaging (message in the "data packet" sense) * sear…

> Over the next 10 years I think we're going to see more and more codeless SaaS services Maybe it will finally happen, but some variation of this has been the holy grail for a lot of years now. I read an article a while back that talked about how many times developers have implemented the same thing in different ways at different companies; for instance payment processing. And it's true. But, you have companies like…

I suppose another way of looking at it, is more about what you've mentioned with Stripe, Braintree, etc. A lot of the things that a web business needs to run are getting built out as APIs. At some point, I predict non-tech companies that still need some tech components, they will:

  * pick out the SaaS they need, and someone will write a tool to integrate the top different SaaS providers together
  * they will differentiate themselves from their competitors based on their product offering and branding, less so on tech
So, I'm not saying that programmers in general will be able to plug and play backend infra like Legos, but that non-technical people will be able to mix and match the infra components they need without doing coding. For these kinds of people, what the computers are doing is not important, and the frontend is more important, IMO.

Re: Second-Guessing the Modern Web

#410

Post by benibela »

int_19h wrote: post #269
jimbob45 wrote: post #247

Earlier quoted context omitted.

RAD died because it could only cover 98% of business needs and idiot managers thought they needed a language to deal with 100% and so threw away really great tools. I could fully foresee VB making a comeback in the future.

RAD never really died, we just stopped calling it that. But open Visual Studio today, and create a new Windows XAML app, then open the form designer. You can still drag a button from the toolbox, move it around, then double-click it to wire up an event handler - exactly like it was in VB6. In fact, it's quite possible to ignore all the modern stuff like data bindings entirely, and just manually read and update all wi…

A typical Delphi app might have done that, but a selling point of Delphi was that it had data binding.

Connect the TDB* vies to a TDataSource, and it would show the values of a database, without requiring manual updates.

Post reply on HN