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

441–450 of 467 posts

Re: Second-Guessing the Modern Web

#441

Post by thomasfromcdnjs »

arvinsim wrote: post #274
burlesona wrote: post #72

Earlier quoted context omitted.

For the most part I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting. If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most. For the hipsters, the problems of SPAs are hard, and engineers like hacking on hard problems. Also the fact that the…

> Also the fact that the solutions don’t work very well means they’re constantly being reinvented, which means if you do the work to keep up with it all you’re rewarded by being regarded as an expert, which is nice. This is a huge assumption. For example, I don't think any web dev enjoys wrangling with CSS positioning or workarounds because they want to be "rewarded by keeping up". > Last year I assigned a feature to…

Yeah I'm also laughing.

The senior engineer could have just as easily wrote worse code.

Just some weird obscure Javascript floating around editing the DOM directly causing untraceable errors in the future.

React helps with lots of things;

- Testability

- Readability

- Less side effects

- Documentation

- Rendering

- Error Protection

I could rattle on forever, might be time to write a blog post, gets a bit tiring reading the HN users who think we've just made the frontend complex for fun.

Frontend development is HARD, factors include;

- Plethora of device models/sizes

- Latency / Async / Fetching (data)

- Rendering speeds based off how you coded it

- State Management / Cache Freshness / LocalStorage

- Server Side Rendering

- Code Bundling (js and css)

- Design / Transitions / UX / UI

etc

Now why is all this important? Because to be a competitive app, it simply has to be sexy and slick.

If I could do that with one style tag and one script tag, I would.

Re: Second-Guessing the Modern Web

#442

Post by mattmanser »

bobthepanda wrote: post #109
conorh wrote: post #81

Earlier quoted context omitted.

I disagree. Do you remember the days when J2EE was the hot stuff? Popularity comes and goes and is not necessarily correlated with whether something is a good idea or not. Over the last 15-20 years or so as a web development shop we've gone through Prototype, Jquery, Backbone, Angular, Vue and now React for JS frameworks. We've mostly settled on React lately. Our experience is however that it is wildly overused where…

> Features that should take a week to build now suddenly have complex client side state management requirements (to name one issue) This sounds like bad system design rather than a problem of React. In general, I find React hate massively overblown. The problem seems mostly to be that everyone is using it, and "everyone" in the case of frontend devs is all over the place in terms of how they got there, what they know…

This sounds a lot like the days in web dev before Ruby on Rails came along.

When they (and django) took the web dev world by storm they were prescriptive and told developers how to do something, not just giving them a bunch of tools where you had to build your own app lifecycle, usually massively over-engineered. A whole load of mental overhead disappeared.

Just before Rails, etc. everyone was going on about Factories and the Gang of Four and people were building crazy startup patterns on their webapps using Singletons.

Re: Second-Guessing the Modern Web

#443

Post by mattmanser »

int_19h wrote: post #431
benibela wrote: post #410

Earlier quoted context omitted.

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.

VB6 and WinForms also had data binding. But in practice I've rarely seen it used, except for data grids.

WPF has databinding available today, it's not gone away.

https://docs.microsoft.com/en-us/dotnet/desktop-wpf/data/dat...

Re: Second-Guessing the Modern Web

#444

Post by mattmanser »

aryehof wrote: post #215
PaulDavisThe1st wrote: post #161

Earlier quoted context omitted.

What do you consider "our industry" to be ? Software development? Web development? What used to be called "Application Development" back in the 1980s and early 1990s? I'm asking because there's a lot of software developers/engineers whose jobs don't feature any of the keywords in your comment ("Frontend", "Backend", "SQL queries", "modal" etc. etc.)

If all one has been exposed is a development world of web-based consumer-facing front-ends (CFUI), it is hard to imagine that the majority of software lies elsewhere. Hard to imagine that anything else is important. It leads to a viewpoint that modern programming is mainly about UI interacting with a database.

Does the majority of software lie elsewhere?

Type "developer" into a job search.

The majority of all software in the world actually does lie in CRUD web apps today.

Re: Second-Guessing the Modern Web

#445

Post by [deleted] »

WesolyKubeczek wrote: post #335
andrepd wrote: post #311

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. Not exactly making a value judgement about this, but imagine for a moment any other engineering discipline saying this: Yeah, I kinda made this road 20x less efficient that I could have, but I didn't want to bother with the nitty gritty details. Yeah I'm using trash materials to make this buildin…

You would be shocked to learn how many roads and buildings are actually built like this. Except that in the case of roads and houses, people die sometimes as a consequence.

[deleted]

Re: Second-Guessing the Modern Web

#446

Post by ryanbrunner »

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.

This doesn't match my experience at all. I've seen many, many places where a bleeding-edge React stack was deployed to serve what was 100% static content.

Re: Second-Guessing the Modern Web

#448

Post by int_19h »

mattmanser wrote: post #443
int_19h wrote: post #431

Earlier quoted context omitted.

VB6 and WinForms also had data binding. But in practice I've rarely seen it used, except for data grids.

WPF has databinding available today, it's not gone away. https://docs.microsoft.com/en-us/dotnet/desktop-wpf/data/dat...

For WPF, data binding is idiomatic. It wasn't back in those days.

My point is basically that the tooling that we use for desktop UI development is still very much rooted in the RAD era - but as best practices around it changed, we dropped the "RAD" label. It was a gradual evolution, though.

Re: Second-Guessing the Modern Web

#449

Post by chrischen »

doteka wrote: post #287
chrischen wrote: post #180

Earlier quoted context omitted.

I did address that it depends on your requirements. But my point is that it is highly unlikely that any requirements would be better served by vanilla JS + html than say writing your code with ES Next or React, unless you truly have some sort of limited use one-off thing. Tools like webpack, babel, and react are also orthogonal to whether or not you're doing an SPA. These new tools aren't just to make your app a SPA,…

I have been working with various SPA frameworks for about 5 years now, from the bad old days of AngularJS to mostly React nowadays. Your comment about 1990 seriously rubs me the wrong way because it seems to imply React et al. actually does something to address the points you make. It does not, at all. You still need to test your code on every viewport you support. And now you have to deal with an insane build proces…

Yes you still have to test your app on different platforms and browsers, but the point of the build process is that they make them work on those various platforms, whereas before you would have to manually fix those failed tests and hack in fixes for obscure conditions. That's what frameworks and libraries are for. They've abstracted away things so you can focus on higher level things. Tests are always going to be required, even if your framework and libraries are perfect.

We don't need to stay close to the platform because abstractions allow for more advanced applications. That's why most web apps don't use C, and should never use C, because 99% of the coding work is higher level tasks that don't need the bare-metal performance optimizations.

Re: Second-Guessing the Modern Web

#450

Post by chrischen »

ratww wrote: post #282
chrischen wrote: post #180

Earlier quoted context omitted.

I did address that it depends on your requirements. But my point is that it is highly unlikely that any requirements would be better served by vanilla JS + html than say writing your code with ES Next or React, unless you truly have some sort of limited use one-off thing. Tools like webpack, babel, and react are also orthogonal to whether or not you're doing an SPA. These new tools aren't just to make your app a SPA,…

> Tools like webpack, babel [...] but are meant to decouple the maintainability of your code from the implementation details. Let's be real, the only reason we really need WebPack and Babel at this point is for IE11 compatibility and JSX. Currently >90% of the browsers (that depends on the country) are evergreen, and have support for most ES6 features, including ES6 modules. As soon as we're able to drop IE11 (when w…

Babel is there so you can write your code with the latest Javascript features and separate your written code from what is actually deployed. JSX and IE11 are a subset of problems that this type of abstraction can solve.

This is miles better than the previous alternative: manually importing shims or adding in css prefixes. Babel and webpack also enable macros and static code analysis tools so you can write code in "inefficient" ways that's more readable, and automatically generate more performant code automatically.

Browsers are still split, even if considering only desktop users. If you add in mobile users then all those iOS people are using Safari, not Chrome.

And because of this fragmentation you can't expect the latest ES features to be usable on day one. So you'll always want Babel so you can write the code the way you want, and have platform targeting be a separate concern.

It sounds like you believe that we should be writing very platform specific code for the web, which is a bad practice in general. Nobody should write platform specific code. Leave that to the compiler.

Post reply on HN